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Vim is an experimental computer system being developed at MIT for supporting functional 

programming. The execution mechanism of the computer is based on data flow. This thesis presents 

mechanisms for managing data structures in this system. The thesis also develops a methodology for 

designing computers, which is based on successive refinement of formal models of the computer. 

A formal model LI of the abstract architecture of Vim is first developed. The behaviour of this model is 
described by its operational semantics; LI is the specification of Vim. LI is then refined to model hierarchical 
physical storage consisting of main memory and disk. This refined model is called L2. The unit of storage 
allocation and of data transfer between main store and disk is a chunk. The thesis proposes a new data 
structure called VlM-tree which is a tree of chunks. Data structures in Vim (arrays and records) are stored on 
VlM-trees. VlM-trees allow efficient applicative operations on data structures and permit a large amount of 
sharing. A reference count mechanism is proposed to perform automatic storage reclamation. Special care is 
taken to handle operations in L2 on data structures containing early-completion queues and suspensions, which 
are distinctive features of Vim. A base language for this machine is outlined in the thesis. 

The models LI and L2 are then shown to be equivalent for the proposed base language. The 
equivalence is proved by exhibiting a McGowan mapping between the states of the two models during the 
execution of a program writen in the base language. 
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The woods are lovely, dark and deep 
But I have promises to keep 
And miles to go before I sleep 
And miles to go before I sleep. 

- "Stopping by woods on a snowy evening" 
Robert Frost. 
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§ 1 INTRODUCTION 

Chapter One 
Introduction 



In recent years data flow computer systems have been the focus of vigorous research, especially in 
the context of high speed scientific computations. In addition to higher speed, the data flow model of 
computation appears to provide a more robust programming environment than is available on 
conventional systems. The VIM project of the Computation Structures Group at MIT is aimed at 
examining the issues involved in implementing a modern, general-purpose computing environment 
based on the principles of dataflow that can effectively support such diverse computational applications 
as database systems, logic programming, etc. The ideas about the VIM system have evolved over the 
years, drawing much from the works of Dennis [9, 10, 11], Paul [31] and Weng [38]. 

The VIM system will support functional programming and the execution mechanism is based on 
data flow. In the world of functional programming all values are treated as mathematical values. This 
implies that the traditional view of data structures (arrays and records) as modifiable entities is no longer 
valid - the system must operate so that the user gets the view that a new structure is created from the 
old one whenever required. In a simplistic implementation, this would lead to a proliferation of copies 
of data structures, each differing from the others in only a small number of values. It is recognized that 
sharing of common elements among structures would reduce both the amount of copying and the 
storage space required to run the program. Various proposals have been made to implement data 
structures in data flow systems; none of them can be called definitive solutions. Applicative languages 
are also side-effect free languages and the language constructs provided in the functional language for 
Vim docs not allow the creation of circular structures. Therefore, reference-counted memory 
managemenrt becomes an attractive alternative to traditional mark-and-sweep methods for garbage 
collection. This thesis proposes a representation for data structures that greatly reduces the amount of 
copy ing and describes a reference count mechanism for storage reclamation. 

In most currently proposed functional language architectures, an implicit assumption is that the 
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program and the data which the program operates upon are all located in the main memory 1 . Vim has a 
two-level physical hierarchy of storage consisting of a large, slow disk and a smaller, faster main store. 
Values in the main-memory can be accessed immediately while values which are resident in the disk 
must be read into the main memory first. 

The problem of storage reclamation on systems with large address spaces is a prickly one; the 
strategy for garbage collection in Vim is based on reference counting. The architecture of Vim modelled 
in this thesis consists of a single processor, some main store and disk store. The principal source of 
parallelism in the single-processor version of Vim stems from the concurrency in the processing of 
instructions and disk activities. 

1.1 The VIM Project 

The goal of the VIM project is to develop a computing environment which supports functional 
programming and provides a large address space and automatic storage reclamation. A two-level 
physical storage has been chosen to reduce the cost of physical memory. The primary vehicle for 
programming on this system will be the VimVal language, a functional language that is an extension of 
the language Val developed by Ackerman and Dennis [1, 26, 27]. The criteria that have guided the 
design of the new language are that it should have the following characteristics. 

• It should be sufficiently expressive in that it provides language constructs to the 
programmer to express most application programs that he needs to, without 
having to appeal to some features of the underlying architecture that are not 
evidenced in the language. 

• A program consists of one or more modules. Modules must be independently 
compilable. All the independently compiled modules of a program are linked 
prior to execution by a ljnkcr. 

• The language must be strongly typed, i.e.. if the compiler and the linker certify 
the program to be legally typed then ihe program will not encounter any type 
errors at the time of execution of the program. 

• The language must provide constructs to express computations on streams. 
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• Non-dcterminacy must be expressible in the language. 

• Higher-order functions must be permitted. 

Programs written in VimVal will be run on a data flow processor with hierarchical storage. The 
conceptual framework for the machine was described in [38]. As currently envisioned, the Vim system 
consists of a single processing element and a two-level physical storage consisting of main memory and 
disk. 

1.2 Background and Previous Work 

A number of projects have aimed at providing a coherent and structured programming 
environment within the framework of a multiprocessing system. Of principal interest from the 
perspective of this thesis are the Hydra/C.mmp system, the Cm* computer and the SYMBOL 
computer. 

The Hydra/C.mmp was an experimental multiprocessor system [39]. Capabilities were adopted as 
a mechanism for providing a large and uniform address space and also to control accesses to shared data 
structures. However, the system fell short of providing a truly integrated interface between the 
capability architecture and the programming language. The task of processor management was left 
largely in the hands of the user. The user had to ensure the correct usage of shared data structures by 
the use of appropriate locking and synchronization primitives, with a resultant decrease in the 
programmability of the system [23]. However, in spite of these shortcomings the Hydra/C.mmp system 
represented a significant advance in programmability over the multiprocessor systems then existing. 

The Cm* [34, 35] was also a capability based architecture consisting of a large number of 
processors and memory' modules. An underlying goal of the Cm* project was to develop a system that 
would be scalable, i.e., the computing power of the system would grow in proportion to the number of 
processors in the system. However, this effort too left the issue of processor management as a user 
responsibility. Also, since the cost of a memory access was proportional to the distance of the memory 
cell from the processor, the task of organizing the program so that the number of non-local memory 
references would be minimal was left to the programmer [22]. 
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The Mu project [18] at MIT was aimed at assessing the importance of programmability in 
multiprocessor organizations. Though the theoretical framework appears to provide a better working 
environment than in Cm* and C.mmp. the system was still unable to provide an elegant way of avoiding 
the need for explicit synchronizaton mechanisms for shared data that could be updated independently 
by the processors. It became clear from Halstead's work that the language supported by a 
multiprocessor is critical to the usability of the system. The difficulty of programming on a 
multiprocessor can be alleviated if the user can write programs without having to worry about task 
scheduling, process synchronization and hazards such as read-before-writes, such chores being taken 
care of by the underlying system automatically. 

The SYMBOL computer system [8, 29] was a language based multiprocessor system that allowed 
the user to program without having to worry about low level considerations like mapping the tasks onto 
the processors. Each of the processors had a very specific task; however, the task division was so rigid 
that it ruled out the possibility of scaling the system. Also, the various processors did not aim at solving 
a single problem in parallel. There was a processor dedicated to compilation, one to memory 
management, one to I/O management, one that actually executed the compiled program, etc. The 
parallelism in this system resulted from the fact that memory management, input-output and actual 
processing could be done in parallel. There was no facility in the system whereby multiple processors 
could concurrently execute a compiled program. 

The SYMBOL was not a true multiprocessor since it was unable to support parallel execution of a 
program exhibiting a lot of computational parallelism. However, many of the ideas it introduced were 
far ahead of the times. It was one of the first processors to specialize the memory architecture to 
support structure memory. The memory representations of data were specialized to reflect the type of 
data, allowing operations to be performed on such typed data more efficcicntly. Significant amount of 
specialized hardware was developed to allow structure operations to be executed fast - a revolutionary 
approach, considering the cost of hardware in that period. 

One of die seminal contributions of the SYMBOL system is tli at it \icwed that die design of the 
memory management svstem was an integral part of the multiprocessor system design. The memory 
management mechanism provided primitives which could support high-level mcmor\ abstractions such 
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as stacks, queues, lists and strings. A specialized processor performed the memory management tasks, 
exemplifying the philosophy of static load distribution that so characterized the system. 

In spite of its failings, the SYMBOL system, which predated the other projects discussed above by 
a number of years, presented a pointer to the direction in which the development of programming 
environments for multiprocessor systems ought to proceed - an architecture based on a high-level 
language that provided a very uniform, integrated environment for programming. 

Among the various general purpose computing enviroments available on modern systems, the one 
on the Lisp machines deserve special mention. Lisp machines are language-based uniprocessors 
designed at Massachusetts Institute Technology [24, 28, 32, 33, 36]. They provide a uniform 
programming environment; there is no distinction between the command language used for interaction 
with the system and the principal programming language supported (Lisp), the hardware is tailored for 
processing Lisp primitives, high level data structures such as lists and arrays are regarded as data types 
even at the machine architecture level, and mechanisms for storage reclamation constitute an integral 
part of the system design. 

Lisp machines provide a very large address space which can be effectively used to support a 
uniform addressing scheme for all objects created in the system. However, the necessity of explicitly 
"loading" a file containing an object residing in secondary storage before the object can be used detracts 
from the uniform addressability feature. Once the file is loaded, the object may be placed on the disk 
by the memory manager; references to this object are handled by the system so that its actual placement 
in the memory hierarchy is transparent to the user. Ideally, the user should never have to worry about 
whether the object is in the primary storage or in the secondary; given the name of the object, the 
system should automatically resolve the references to the object appropriately. In the VIM system, 
there is no concept of a file - all data structures are persistent in that they continue to exist across 
sessions, until there exist no references to the structure in the system, in which case they arc discarded. 
This strategy obviates the necessity of "loading" files. 

The storage reclamation scheme adopted by the Lisp machine is a variant of die mark and sweep 
strategy I he process of marking and sweeping the address space suns when the system runs out of 
storage. In ihe Lisp machine, the process of garbage collection is overlapped with the processing of 
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other tasks in the system. This overlap is achieved by frequent switching of the task of reclamation with 
other activities. In conventional systems (von Neumann derived architectures), the switching of tasks 
involves the execution of substantial amounts of code to save the state, reducing the efficiency of the 
process of switching. The data flow model of program execution allows such switching to be performed 
with only a small overhead. In mark-and-sweep garbage collection, the time required to reclaim storage 
is proportional to the size of the address space over which the reclamation is to be performed. By 
constrast, the time required to reclaim the storage occupied by an object by reference-count based 
reclamation schemes is proportional to the size of the storage occupied by the reclaimed objects. 

1.3 Outline of the Thesis 

The design of the Vim architecture espouses the following philosophy. An architecture should be 
developed by successive refinement, starting from an abstract mathematical specification. The 
extensions and refinements at each of specification are designed to permit more efficient 
implementation of the machine. By proving that all the models are equivalent 2 , one can largely 
eliminate the unexpected behaviours that one encounters when designing a system in an ad hoc basis. 
This type of top-down approach is especially important to the design of multiprocessor systems, since 
the possibility for errors of omission and commision is so much greater. 

The design of the Vim system started with the design of the language VimVal which conformed 
to the aims outlined earlier. VimVal programs are compiled into programs in a base language, a 
preliminary version of which was proposed by Dennis and Stoy in 1982; a refinement of the base 
language is presented in this work. 

In this thesis, first the operational semantics of an abstract model for Vim is described. The 
model, called LI, is the basis for specifying the behaviour of Vim. and is a set theoretic characterization 
of the abstract machine. The execution model is defined by a non-dctcrministic state-transition 
function. The set of instructions in this abstract model is an extension of that proposed by Dennis and 
Sioy. Chapter 2 gi\cs n brief description of the VimVai language and then presents the formal model 
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LI. 

The operational model L2 is a refinement of LI and is obtained by adding the notion of storage. 
In this model, structure values (such as arrays and records) which were modelled as elements of sets in 
LI are viewed as stored values. L2 models a system with a hierarchically organized physical memory 
consisting of main store and disk. Storage consists of a large collection of equal sized chunks, each of 
which is an ordered set of words. Structure values are stored in trees of chunks, thus permitting sharing 
of information. L2 models a strategy for storage reclamation based on a reference count mechanism. 
The operational semantics of this model is presented in chapter 3. 

In accordance with our proposal of designing by refinement, we must next demonstrate that the 
L2 satisfies the specifications of LI. This is shown by proving that the two machines are 
computationally equivalent. A formal definition of equivalence is developed in Chapter 4 and the proof 
of the equivalence of LI and L2 is presented. 

The base language for the machine, which is the target language of the compiler for VlmVal, is 
described in Chapter 5. Essentially, the data flow graphs are such that when the computation of a 
program terminates, the reference counting mechanism would guarantee that if a structure becomes 
inaccessible in LI, the corresponding element in L2 would have reference count of zero and would thus 
be reclaimed. 

The thesis concludes with a discussion of the relationship between L2 and its physical realization, 
and a brief list of related problems which are beyond the scope of this thesis and need further 
investigation. 



THE VAL INTERPRETIVE MACHINE § 2 

Chapter Two 
The Val Interpretive Machine 



The goal of the Vim project is the design and development of a computer system that supports 
functional programming well. The architecture of the computer is based on data flow principles and the 
data flow model of program execution is well suited for interpreting functional languages. 

The functional language suuported by Vim is VlmVal, which has evolved from Val. VlmVal is a 
textual language and a brief description of it is given in the first section. VimVal programs are 
compiled into programs in the base language, which consists of a set of data flow graph schemata. 
Translation from VimVal to the base language is straightforward since each construct in VimVal 
corresponds to a graph schema in the base language. 

Programs in the base language are executed by interpreting the data flow instructions which are 
the nodes in the data flow graph for the program. Section 2.3 gives an informal description of some of 
the distinctive mechanisms used in Vim. The operational semantics of the abstract model LI is 
presented in section 2.4. The model is the specification of Vim and all implementations of Vim must 
meet the specifications. 

2.1 The VimVal Language 

The programming language for the Vim system is the VimVal, an applicative language which is a 
revision and an extension of the Val programming language. The extensions include the addition of 
stream-types, free variables, recursion and mutual recursion, and higher order functions. A type 
inference mechanism guarantees type safety even if most type declarations are absent. Type inference is 
also used to provide polymorphic functions. 

I he data types of YimVai fall into two classes - sitnph types and structure types. The simple 
types include the familiar types intc»er. real, boolean, character and null. The structure types include 
array -types, record-types, distinguished unions, stream-types, and functions. 



S 



§ 2.1 THE VAL INTERPRETIVE MACHINE 9 

Functions are first-class objects. They may be passed as arguments to and returned as results from 
functions, and they may be built into data structures. The body of a function definition is an 
expression. Evaluation of an expression yields a single value or a tuple of values. Forms of expressions 
include the conditional expression, the tagcase expression, and the function invocation. There is no 
form of expression for expressing iteration, use of recursion being preferred. 

2.2 An Example Program in VimVal 

A program in VimVal consists of one or more modules. Each module has a header specifying its 
interface, type declarations, function definitions and one expression which constitutes the body of the 
module. An example module is shown in Figures 1 and 2. Figure 1 illustrates how the user may define 
a new data type List, which represents a list of integers. The example module defines three simple 
operations on objects of type List. Figure 2 illustrates the use of streams in the language. The functions 
car, cdr and cons defined by the example programs have the same meaning as in Lisp. The function 
ListToSlream creates a stream of integers when it is given a list of integers. SumOfStream sums up the 
elements of a stream of integers. 

A module written in VimVal defines a function that may be invoked from within another module 
or by a user command to the system. A module may contain function definitions - these may be 
invoked only from within the module unless they are explicitly exported by incorporating them into 
data structures sent out as module results. The body of a module may use names that are not defined 
bound to values by definitions in the module. These free names must be bound to other modules 
before the module may be run. 

Within a module, type declarations precede the function definitions and the body. Within a 

function, the type declarations must precede the expression that constitutes the body of the function. 

An array A of integers is declared as follows. 
A : array[integcrs] = array(l, 100) 

The elements of the array are initially undefined. sdcctM. /) returns the Value of the /th clement of the 
array. appuid(,f. /. v) creates a new array which i* idcniical to the array A except that the value of the /th 
element of the new arrav is i\ 
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module returns rccoTi[head, tail, luple : function] 
type List - oneof [emptylist : nil; 
atom : integer; 
pair : recorders/, second : List]\ 

function car (L: List) returns List; 
tagcase L 
tag emptylist : error; 
tag atom : error; 
tag pair : L.first; 
endtag 
endfun 

function cdr(L:List) returns List; 
tagcase L 
tag emptylist : error; 
tag atom : error; 
tag pair: L.second; 
endtag 
endfun 

function cons {LI, L2 ; List) returns List; 

make List[pair: rccord\fi rst: LI, second: ZJ]] 
endfun 

recoTd[head:car, taihedr, tuple: cons] 
endmodule 

Figure l: An example program in Vim Val. 



The definition of a record-type is of the form 
type Pair = recorders/, second : List] 

Records of type Pair have two fields named /r//and right. The operation 
record[//rs/ : v/, second : vJ] 

constructs a record where vl and v2 arc of type List. Record fields arc accessed by die select operation, 
for instance 
L.first 

yields the \alue of the hft field of /.. which must bo of type List in which the tag is pair. Tagged unions 
are used where different choices of representation arc appropriate for different cases of a value. Kor 
example, the type List is a tagged union. 



§2.2 TliFVAL INTERPRETIVE MACHINE H 



function LisiToStream (L:List. C.List) returns strcam[integerj 
tagcase L 
tag empty : tagcase C 

tag empty : streamQ; 
tag atom : affix(C, streamQ); 
tag pair: ListToStream{car{L\ cdr{L)) 
endtag 
tag atom : affix(L. ListToSiream{car{L), cons(cdr(L), Q; 
tag pair : LisiToSlream(car{L\ cons(cdr(L), Q) 
endtag 
endfun; 

function SumOfStream(S:strcam[mlegcT]) returns integer; 

if isempty(5) then 

else first(5) + SumOfStream(rest(S)) 

endif 
endfun; 

Figure 2: Continuation of the example. 



type List = oneof [emptylist : nil; 
atom : integer; 
pair : record [first, rest : List]\ 

where the subtypes are distinguished by the tags emptylist, atom and pair. make[a/om : 0] creates a 

oneof in which the tag field is atom and the associated value is 0. A case expression is used to access 

values of a oneof type : 
tagcase L 
tag emptylist : exprl; 
tag atom : expr2; 
tag pair : cxpr3 
endtag 

A stream is a sequence of values, all of the same type, that arc passed in succession, one-at-a-timc 
between functions. The operations defined on streams arc Q. first, rest, affix and empty. Q produces an 
empty stream. first(5) produces the first element of the stream S. The result of rcst(.V) is the stream left 
after removing the first clement of .V. affi\(v, S) is die stream whose first clement is v and whose 
remaining elements arc the stream .V. The result of emphf.S) is true ir .V is an empty stream, false 
otherwise. 
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2.3 The Val Interpretive Machine - Vim 

The abstract architecture of Vim uses data driven program execution. A program in the base 
language consists of one or more functions, each represented by an acyclic, directed data flow graph. 
The nodes of the graph are the instructions and the arcs between the nodes specify the data 
dependencies among the instructions. Arcs connecting two nodes may be of two types - value arcs and 
signal arcs. Values are carried on tokens along the directed value arcs of the graph. A Junction template 
is an array of the instructions which belong to the data flow graph corresponding to a function 
definition in Vim Val. The size of the array is equal to the number of instructions in the data flow 
graph and the indexing of the array starts from 1. Instructions are identified by their array indices 
within a function template. 

In Vim, iteration is modelled as recursion, and the chosen method for implementing recursion 
avoids the use of cyclic graphs 3 . Instead, each function application uses a fresh copy of the graph 
represented by the function template, the copy being called an activation template. An instruction is 
enabled or ready for firing when a value is available on each input value arc, and a signal has been 
received on each signal arc. Note that it may happen that some instructions in a template 4 will receive 
values but will never fire because no signal will ever arrive. In chapter 5 we give rules of graph 
construction to ensure that this does not happen; otherwise, the storage reclamation scheme will be 
unable to reclaim all possible structures, leading to degraded memory utilization. 

A salient characteristic of Vim is that no arc is ever reused - at most one value or signal will be 
sent from one instruction to another along a value or signal arc of an activation template, respectively. 
This is assured by the acyclic nature of the data flow graphs and by the property that each function 
application produces a new activation template. This is quite different from the data flow models used 
by die U-Intcrprctcr{2] or the Static Data How machine [14. 12). In the static data flow machine, the 
data flow graph docs not change during program execution. The creation of function activations 
provides a very natural way of implementing recursion in Vim. Vim is similar to the static machine in 
that instructions have special fields for holding the operand values. This is quite unlike the mechanism 



I urn or uses ache graphs 10 implement recursion in [.17j. 

4 
Wc shall use "icmplaic" instead of "actuation template" whenever there is no cause for confusion. 
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used in the U-intcrpreter where the value is stored in an associative store. Function application in Vim 
expands the execution graph due to the creation of activation templates; the graph contracts whenever a 
function terminates and the activation is discarded. In the U-interpreter function application results in 
the creation of a new context, which is a part of the tags on values. 

Another feature of Vim which distinguishes it from other data flow models such as the U- 
interpreter or the Static data flow machine is the heap. Vim maintains a heap in which all objects except 
scalars that enter into computation are held. Scalar values are stored in the operand fields of the 
instructions, and passed around among the instructions on the tokens. The kinds of objects held by the 
heap include function templates, closures, early-completion queues (described below) and data 
structures (arrays, records, etc.). Each object on the heap has a unique identifier which permits its 
selection from among all objects in the heap. Conceptually, the heap is a multi-rooted, directed acyclic 
graph in which an arc signifies that the target object is a component of its superior. 

A distinctive feature of Vim is the set of mechanisms designed to support aspects of the VimVal 
language; in particular, these include support for function application and tail recursion and 
computation on streams. These mechanisms are described informally below; a formal description of the 
mechanisms will be presented in the next section. 

2.3.1 Function Application 

Function applications are made by the apply instruction, which requires two operands - a 
function closure for the function to be applied, and a data structure containing argument values. The 
first element of the closure is the uid of the function template which is to be applied; the rest of the 
closure contains information defining the binding of any free variables of the function. The apply 
instruction creates an activation of the function by copying the function template. It then sends die 
closure, die argument structure and the return link to the first operand of the first three instructions in 
die activation template, respectively. The return link consists of the uid of the calling activation and the 
uid of the destination list of APPLY. 

Instructions of die actuation are then executed according to the data flow firing rule until the 
RlTLKN instruction is enabled. The ri iirn instruction uses die return link to send the result of the 
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function invocation to the recipients. Due to the presence of early-completion structures the return 
instruction may not be the last instruction to execute in the activation. A separate RELEASE instruction 
releases the storage occupied by the activation template. 

The following notation will be used for drawing data flow graphs. The nodes of a function 
template are instructions drawn as rectangular boxes. The value arcs connect from bottoms to tops of 
instruction boxes and convey data values. The signal arcs convey signals that perform control functions 
such as the release of function templates. The signal arcs connect from right sides to left sides of 
instruction boxes. Numerals at the left corner of instruction boxes denote the index of the instruction in 
the activation. A Greek letter next to an instruction box corresponds to the address of the instruction, 
consisting of the uid of the activation template and the index of the instruction. An open box with two 
or more values or signals is the merge operator. The graphs are arranged such that exactly one Value or 
signal will arrive at a merge box. This is merely a notational convenience; in Vim, the signal count and 
operand counts are set such that the merge occurs naturally. 

Figure 3(a) shows a data flow graph which causes a function activation. A. is the address of the 
destination instruction of apply, which is sent to the third instruction of the activation created by 
apply. Figure 3(b) shows a typical function template. The RETURN instruction receives the destination 
list consisting of the address A; when it receives the result computed by the function body, it sends the 
result to the instructions whose addresses are listed in the return link and sends a signal to a release 
instruction. 

In many cases the value returned by a function / is computed directly by a tail-recursive 
application off, as shown in Figure 4. In this situation the result to be returned by the caller is exactly 
that returned from the callce. and the reactivation of the caller is unnecessary. The Tailapply 
instruction in Vim implements this. It also causes a function activation but is different from apply: it 
has an extra operand, a return link which it passes to the callce instead of generating a new one; also, it 
sends signals to the instructions whose indices arc in the destination list of the tailapply instruction. 

higure 4(a) shows the tailappi Y instruction and illustrates the operands that it needs. Figure 
4(h) shows a typical template corresponding to a Liil-recurshc function. The switch instruction ukes 
two operands: if its second operand, wheih must be boolean, is true then the first operand is sent to all 
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(a) 




argument record 



Function template 
for F 



(b) 



argument record 

Q 




value arc \ signal arc 

Figure J: (a) shows the data flow graph for function imocation (h) l)aia flow graph of a Upical function template. X 
is tiic address of the destination oI'appi v: it is a pair consisting of (ho uid of the calling aci nation and the index orihe 
instruction in the template. 



the destinations of SWITCH whose addresses arc marked true in its destination list and if it is false then 
the first operand is sent to the destinations marked false. The function body determines if no further 
applications arc to occur, in which Rnu<\ is activated, otherwise die i All aiti y instruction is enabled. 
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(a) 



return link 



argument record 




Function template for F 



^ return link 
Q 

3: 



SWITCH 



RETURN 



SWITCH 




closure 

Q 



argument record 

o 



1_T 




SWITCH 



SWITCH 



_L_±. 



TAILAI'PLY 



Figure 4: (a) The taii apply instruction, (b) Typical data flow uraph for the bod> of a tail-recursive fur 
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2.3.2 Early-Completion Queues 

In computations involving data structures, concurrency is increased if a data structure can be 
made available for access before all the component values have been computed. If instructions are 
required to receive all their operands before their application, as is usual for the execution of data flow 
programs, this concurrency of creating and accessing a data structure is not possible. 

In Vim there is a special facility called early-completion queue (abbreviated EC-queue) to permit 
structures to be created before the values of all the components are available. Arrays will be used to 
describe the early-completion mechanism informally (figure (5). The behaviour of structures containing 
EC-queues is specified by the state- transition rules of the mkinarrayec, select, append and SET 
instructions. 

An EC-queue is a collection of addresses of instructions, mkinarrayec creates an array in which 
all the elements are EC-queues, all initially empty. This shell of the structure is passed onto consumers 
of the data structure, and also to producers which replace the EC-queues by values using the SET 
instruction. If a select tries to access an element which is an EC-queue, its address is added to the 
EC-queue and the instruction is removed from the set of enabled instructions. Eventually, a SET 
instruction replaces the EC-queue by a Value and adds the addresses of the instructions in the EC-queue 
to the set of enabled instructions. When these instructions are attempted for execution again, they 
would read the value, as desired. Structures with EC-queues provide a powerful mechanism for 
synchronisation, and is an effective solution to the read-before-write problem [4]. 

Figure 5 illustrates the early-completion mechanism. Figure 5(a) shows a data flow graph which 
creates an array of one element which is an empty EC-queue. The array is sent to two consumers whose 
addresses are a and /J, and to a set instruction y. Figure 5(b) shows how the contents of the array 
changes when the instructions a. /? and y fire in sequence. If y fires first, then a and /? can access the 
value in the usual manner: the erstwhile presence of the EC-queue docs not affect subsequent accesses 
after it is replaced. 

I'he early -completion mechanism makes it possible to allow function applications to begin 
execution before die \altics of all their arguments ha\e been computed. This is done by packaging the 
arguments into a record of 1 c -elements. Similarly, die result values, if there arc more than one. mav be 
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returned as a structure of EC-elements so each may be available to the caller without waiting for all the 
results to be evaluated. 



(a) 



1 1 

i A. 



MKINTARRAYEC 



SET -i 



: A ▼ L, a:, 1 i. 



SELECT 



fi- 



L_i 



SELECT 



(b) 



1 




ecq 




a fires 



P fires 



1 



(jT?) 



f fires 




1 



a 



*7 



1 



^ijb/v 5: (a) Data flow graph showing producer-consumer relationship for structure containing EC-queue, (b) The 
contents of the array under the firing of a, fi and y in sequence. First, the firing of a causes a to be added to the 
EC-qucuc. which was empty Next /} attempt* to access the element and also gets added to the EC-queue. Eventually 
when x is computed, the sxr fires. It replaces the EC-queue with x and adds o and /? to the set of enabled instructions. 



The semantics of arrays with ecqueucs is very similar to the semantics of 1-struclures, which were 
proposed by Arvind and Thomas [5]. An 1-structurc is a linear contiguous data structure: an element of 
an l-siructtirc e\m be written into at mosi once. Roads occurring before an clement has been written 
into are deferred until the arriwil of the value. Y\w futures construct of Halsiead [19] is also of similar 
flavour. 
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2.3.3 Suspensions and Streams 

Stream structures are an attractive language feature since they permit the producer and consumers 
of the stream to operate concurrently. Vim provides a special mechanism for efficient implementation 
of streams. A stream is represented in Vim as a chain of records of two elements, each of which is an 
EC-queue; the First element contains an element of the stream and the second element is a pointer to the 
rest of the stream. In a completely data driven evaluation of a stream, the producer would proceed at its 
own pace and generate the values to construct the stream. The consumer process accesses the elements 
of the stream at its own rate, waiting whenever it encounters an EC-queue until the value is supplied. 

The problem with this scheme is that it allows the producer to get arbitrarily far ahead of the 
consumer process. If the consumer needs only a part of stream then substantial computation performed 
by the producer may wasted. In particular, if streams are evaluated in a data driven manner, then 
infinite streams cannot be supported on Vim. So streams are produced in a data driven manner, 
allowing the user to write programs in VimVal which deal with potentially infinite streams. 

Vim uses suspensions to implement demand-driven evaluation of streams. Suspension 
mechanisms have been used to implement infinite data structures by Henderson [20], Friedman and 
Wise [16], etc. In Vim. a suspension contains the address of an instruction, consisting of the uid of the 
activation template of the instruction and its index in the template. When a select instruction tries to 
access an element which is a suspension, the suspension is replaced by an EC-queue containing the 
address of the select and a signal is sent to the instruction whose address is found in the suspension. 
The signalled instruction eventually causes the EC-queue to be eventually replaced by a value and the 
SELECT instruction gets the value it was trying to access. 

Figure 6(a) shows the creation of an array whose only element is an EC-qucuc. If SETSL'SP fires 
before SELECT, it finds an empty r.c-qucuc and replaces it by a suspension. When sn ECT executes, the 
suspension is replaced by an EC-qucuc containing the address /? of SEI ECT and a signal is sent to the 
instruction indicated in the suspension. If sn rcr fires first, it is enqueued in the FC-qucuc; SITSL'SP 

executes, finds a non-cmpt> EC -queue, and simply sends a signal. The graph is arranged such that the 
armal of the signal inmates a computation that ultimately enables a SI I instruction. The SET 
instruction replaces the I (-queue in thisarra> by a \alue and sen ices the I C -queue bv adding the set of 
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instructions whose addresses are in the EC-queue to the set of enabled instructions. 



(a) 



1 1 

i i 



1 * 



* MKINTARRAYEC 



(b) 
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1 =^ > _t 



causes a signal to 
be sent to ("p A > k) 



fi 



fi 



Figure 6: (a) Creation of an array with a suspension element, (b) Effect of firing of su kt and sitslsp instructions i 
different orders. 



he use of suspensions for generating tlic elements of a stream is shown in Figure 7. Hie records 
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which constitute the stream have two fields which arc named head and tail. The stream consists of 
successive integers. Figure 7(a) shows an initial stream whose first element is 1 and the tail component 
is a suspension. When a consumer a tries to access the tail of the stream, the suspension is replaced by 
an EC-queue containing the address of the consumer (7(b)). A signal is sent to the suspended 
instruction which causes the EC-queue to be replaced by new record whose head component contains 
the next element of the stream and the tail component is a suspension (7(c)). The consumer which tries 
to access the rest of this stream in turn replaces the suspension by an EC-queue. If there are no 
consumers which have pointers to the beginning of the stream then the element at the front may be 
abandoned (7(d)). Suspensions can also be used to advantage for evaluating the elements of arrays in a 
demand driven manner. The main benefit in doing this would be that array elements which are never 
read need not be computed, thus reducing the amount of computation performed. 

The rest of the chapter gives a mathematical specification of Vim. The operational semantics of 
the instructions of Vim are presented. The specification will be called LI in this thesis. LI will serve as 
the basis for the development of an operational model for Vim in which storage is modelled; that model 
will called L2. 

2.4 Operational Model for Vim - LI 

The Vim interpreter has two components : a function Interp and Slate. Interp takes two 
arguments - a Slate and an enabled instruction (defined later) and produces a new State of the 
machine. The following notation will be used in the thesis. Sets are denoted by bold font, elements of 
sets (which may themselves be sets) are denoted by italicised letters and names are indicated in a 
distinctive font. Thus, This is a set. This € This and TKiS is a name. 

The actions of the intcrprctcr'arc described by state transition rules. A programming languagc-ish 

description is used to specify the rules for mapping a set to another set. Mathematical notations such as 

set unions and differences arc used wherever convenient. A rule Fis expressed as follows: 
Define /'M, (/./). v) = 

... body of the rule 

The definitions mav be recursive. 
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Figure?: Demand-driven generation of stream elements, (a) Stream element: the producer is awaiting a demand, (b) 
The consumer demands the next stream element, (c) The producer generates one stream element and suspends itself, 
(d) The consumer abandons the previous element and demands another. 



Vim = </nterp. State> where 

huerp : State X US -* State 

State = Act X H X KIS, 

Act = U — ► Function 

H = U - ST 

U = the set of all unique identifiers. 

KIS = the set of all enabled instructions, described later. 



Act is the set of all actuations: an actuation is created by die invocation of a function. The heap 
II contains all structure values and function templates, caily-complction queues (discussed later). 
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Figure 8: The abstract Vim architecture 



function closures and the instructions. Each element on the heap has a unique identifier (uid). Only 
scalar values and uids are sent on tokens from one data flow actor to another; data structures always 
reside on the heap. 

Scalar values are tagged. 

Scalars = Integers U Reals U Boolcans U Character U Null 

Integers = {int} X (\widef} U the set of all integers) 

Reals = {real} X (\undcj) U the set of all reals) 

Boolcans = {boot} X ({/rue. false, undcj}) 

Character = {char} X ([undcf] U the set of characters in the machine.) 

Null = {null} X {nil, undef] 

The set ST describes the elements which reside on the heap. Elements of different types arc 
distinguished by their tags. 
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ST = {{aTT}X(\myU{undej}))U ({fn}XFunction) 

U ({ecqXECQ) U ({tnst}XInstruction) U {destS}X Dcsts 
U({clsr}XClsr) 

Array = [Integers -*(UU Scalars U SUSP], Integers being the set of integers. 
Function = [N — Instruction], N being the set of natural numbers. 

An early-completion element (EC-element)is a tuple («, ;') where u is the uid of a function 
activation and / is the index of an instruction in the activation. An early-completion queue is a 
collection of such EC-elements. 
ECE = U X N. 

Thus (u, k) € ECE where u corresponds to the uid of a function activation and N is the index of 
the instruction in the activation template. 

The EC-queue is a collection of elements of ECE. All EC-queues are members of the set ECQ 

which is defined below. The notation 9(N) denotes the powerset of the set N. 
ECQ = 9(ECE) 

A suspension is a member of the set SUSP specified by : 
SUSP = {SUSp} X (U X N) 

An instruction is a seven-tuple : 
Instruction = OPS X (U U Scalars) 3 X N X N X U 

OPS is the set of opcodes, the next three elements of the tuple refer to the operands, the fifth and sixth 
elements of the tuple are the operand count and the signal count and the last clement is the unique 
identifier of the list of destinations. Fach destination of an instruction is the index of the instruction to 
which the result is to be sent. The result may be a value or a signal. For / € I. the elements of the tuple 
will be denoted by die 7 notation. Thus. /.Opcode is the first clement of the tuple, /.Opl. /.0p2 and 
/.op3 refer to the second through fourth elements of the tuple, I.opcnt, /.sigent and /.rtestiist 
denote the fifth through seventh elements of the tuple. 

OPS = {|\|)D. ISIR. .. . MKI.VIAr.RAY. \l UN I ARRA VI ('. Sll I CT. Al'l'l ND. SE T. 
SriSlSI'. SWITCH. .Al'l'l V.'IAII Al'l'l V. Rill RN.RH EAST.} 

A destination of an instruction consists of die the address of the instruction to which the result is 
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to be sent, and the operand which is to receive the result value, opl, op2 and op3 denote the first, 
second and third operand fields in an instruction, respectively. If the result is a signal then no operand 
number is required. The destination also specifies if the result is to be sent unconditionally or 
conditionally. For all instructions except for switch, the results of instructions (both values and 
signals) arc sent to the destinations unconditionally. 

Dests = "3(D) 

D = {unconditioned, true, false} x N x {opl, op2, op3, signal} 

Clsr is the set of closure records. The operator (apply, tailapply, stream-apply) which cause a 
function activation take a closure as the first argument. The first component of the closure is the uid of 
a function template; that uid corresponds to the function which is to be called. 
Clsr = [({FunctionToApplu} U M) — (U U Scalars] 

where CYFunctionTo Apply) € U such that H(u) € ({fn}X Function). 

An enabled instruction is an element of EI C U X N. An instruction / becomes enabled when 
/.opent and /.Sigcnt both become zero. The set of enabled instructions describes the collection of 
instructions which are ready to executed because they have received an operand on each of the operand 
arcs and a signal on each of the signal arcs. The set of enabled instructions is: 
EIS = 9(EI) 

The function Choice selects an element from a set of enabled instruction. The instruction is then 

interpreted by the function Interp. Thus Choice is our scheduler; 
Choice : EIS — EI 

Functions AddToHcap and DeleteFromHeap add and delete elements from the heap. AddToAct 
and DeletcFromAct which 

AdJToHeap : H X U X ST — H 

AddToHcapiH. u. v) produces a new function ff such that : 
(V u * u [//"(«■) = H{u)\) and ff(u) = V 

Dclcitl minHcap : II X U X ST -» H Drlcicf-'mniHiviKH. u. I) produces a new heap K such 
th.u the dom.nn of//" is the domain of // without the element w. 
//"such iluMV u* u[H(u) = H(u)\) 
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AddToHeap(H, u, v) creates a new heap which contains, in addition to the associations between 
uids and objects in H, a new association between u and v. DeleteFromHeap(H, u, v) creates a new heap 
which does not contain the uid u in its domain. 

Similarly, AddToAct and DeleteFromAct create new activation sets by adding an activation to and 
deleting an activation from the current set of activations. 
AddToAct : Act X U X Function -» Act 
DeleteFromAct : Act X U X Function -♦ Act 

Function SendResult is used to dispatch the result of an instruction / to a destination instruction. 
SendResult models the following actions : the result is stored in the appropriate operand field of the 
destination instruction, and the operand count and signal count fields are decremented accordingly. 
Since we are dealing with a mathematical representation of instructions and function activations, this 
updating is modelled by producing new values that reflect the changes. Thus, f is the destination 
instruction after it receives the result, FA' is the new new value of FA with the updated / and Act' is the 
same as Act except that the ;th instruction of activation FA has received some operand (or signal). 
SendResult : Act X EIS X U X D X [[{UOlue} X (U U Scalars)] U {Signal}] 

— Act X EIS 

define SendResult{Act, EIS, u FA , (dc, i, opnum), result) = 

let 

FA = Act(u FA ), % FA is an activation template. 

I = FA(i) % I is the ith instruction in the activation template. 

in 

AddToAcHDeleteFromAct(Act, u FA , FA), u fA , FA'), 

if (r.opcnt = 0) A (/.silent = 0) then EIS U {(«_,, /)} 

else EIS 

endif 
endlct 
nhere 

FA(J) = FA(j), ;■*,■." 
= /", ;=/. 
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and V € Instruction, 
/".opcode = /.opcode, 

/\0p1 = if opnum * opl then Aopl else / where result - (value, t) 
r.op2 - if opnum * 0p2 then /.0p2 else t where result = (UOlue, /) 
/\Qp3 = if opnum * op3 then /.0p3 else / where result = (UOlU«, /) 
f.opcnt = if opnum € {0p1.0p2. 0p3} then /.opent else /.opent - 1 
/".silent = if opnum - signal then /.sigcnt-l else /.sigent 
Adestlist = /.destlist 



The function SendToDestlnations sends the result of an instruction to all the destinations of the 
instruction. It is a simple tail-recursive function which uses SendResuh repeatedly to send the value or 
signal to the destination. 

SendToDestinations : Act X EIS X U X 9>(D X ([{UOlue} X (U U Scalars)] U {Signal}) 
-► Act X EIS 

define SendToDestinations {Act, EIS, u, DestValue) = 
if Dest Value = {} then Act, EIS 
else 
let (( dc, d, opnum), V) = e where e € DestValue 
in 
if V = signal then 
SendToDestinations 
(SendResult(Act, EIS, u, (dc, d. Signal), Signal), DestValue - {e}) 
else 
SendToDestinations 
(SendResu!t(Act, EIS, u, (dc, d, opnum), v), DestValue - {e}) 
endif 
endlet 
endif 



Execution of a program on Vim is initiated by the invocation of a function in the base language. 
The execution terminates when there arc no more enabled insrtuctions. The execution loop may be 
summed as : 

define Mainl.uop (State) = 
let ( Act, H,E1S) = State 
in 

if /7.S = { } then halt 

else Mnuil oopi IntcrpiStaie. C lioiciif'lS))) 

endif 
endlet 
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The interpreter is defined by the function Inierp and Choice is a function which selects an element 
from the set of enabled instructions. This instruction is interpreted by Interp in the context of the 
current state of the machine; the result of the execution of the instruction is a new state. Choice is the 
scheduler in Vim since it makes the choice of the instruction which is to be executed. Choice(EIS) 
where EIS € EIS is the address of an enabled instruction. 
Interp : State X Choice{ElS) — State 
where State = Act X H X EIS. 

It is pertinent to point out that Vim is a non-deterministic state transition system; any one of the 
enabled instructions could be selected for execution and the final result of the computation is 
independent of the order of execution of the enabled instructions. 

The following notation is used to denote that the new state (Act', H, EIS) is produced when the 
instruction e is interpreted by Interp in the state (Act, H, EIS). 
(Act, H, EIS) \- (Act', If, EIS) on e. 

Now we can define the interpreter by specifying the state transitions for each of the opcodes. The 
state transitions for some of the more interesting instructions will be presented below; these serve as the 
model for specifying the transition rules for the rest of the instruction set. The body of Interp is a big 
conditional statement; the branches of the conditional are based on the opcodes of the instruction being 
executed. Some general comments are in order here. The result of an instruction is sent to its indicated 
destinations unconditionally, unless it is a SWITCH instruction. 

define Interstate, (u FA , k pA )) = 
let 
FA = Act(u FA ), % the function activation 

I = FA(k fA ), % the instruction 

{(dc { , d v opnumj, (dc r d y opnumj (dc n , d n , opnumj} = /.destiist 

% the destinations of the instruction I. 
in 
if /.opcode = set then ... 
clseif I. opcode. = APPLY then ... 



endif 
cndlct 

I he spec ilicj lit in of the suite transition mles for sonic of the interesting and representative 
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instructions of Vim will be the subject of the rest of this chapter. Each conditional statement of the 
form "if /.opcode = ... then " is an arm of the big conditional statement in Inierp above. Thus, the 

names Act, H, EIS, u fA , k fA , (dc y d y opnum^ (dc n , d n , opnumj will have the same bindings as 

indicated in the body oflnterp shown above. 

Let us begin with the simple instruction iadd which adds two integers. The operands are read 
from the operand fields of the instruction and the result of the addition is sum. This value is sent to the 

listed destinations. Observe that the heap remains unchanged. 

if /.opcode = iadd then 
let 

(int. m) = /.opi, 
(int, n) = /.op2, 

sum = m + n. 
Act', EIS = 

SendToDestinaiioniAct, EIS, u fA , {((unconditional, d v opnumj, aj 

((unconditional, d n , opnumj, a^}) 
in 
Act', 
H, 

EIS-{(u FA ,k FA )} 
endlet 
endif 

where a j € {(value, sum), signal} 

The actions of the interpreter for instructions such as isub, imul. idiv, igt, ilt, etc. are very 
similar and will not be described. 

The instructions which operate on structures produce a new heap. The operations on one type of 
structures - arrays - are described here; the acuons of Interp for instructions which operate on record 
and oneof types are very similar and arc not presented. The array instructions of interest which are 
discussed below are : mkarrayint. mkarrayintec. sn.ncr. append, set and setsusp. 

mkarrayint takes two integer operands (in and /;) and adds an array with bounds (in, n) to the 
heap. All the elements of the array are undefined. The uid of the new army is sent as the result to the 
destinations, alone with siunals if ncccbsarv. 
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if /.OpCOde = MKINTARRAY then 
let 

(int.p) = lop], 

(int, q) = /.op2, % /> a/a/ 9 are integers, p<q. 

u v = a new uid in U, 

/4c/', eist = 

SendToDestinations(Act, E/S, u fA , {((Unconditional, d opnumX a.) 

((unconditional, d n , opnum n ), a)}) 
in 
Act, 

AddToHeap{H, u (an, ([p, q] — undej))), 
EIST - {(u FA , k FA )} 
endlet 
endif 

where a. is either (ualue, u^ or Signal. 

The instruction mkintarrayec works quite similarly except that the elements of the array are all 
early-completion queues, all empty. 

The append instruction takes three operands - an array A, an index / and a value x. It creates a 
new array A which is identical to A except that the / th element of A has value x. It is important to be 
very careful while performing append operations on arrays with EC-elements. If some elements in A 
are EC-elements then the corresponding elements of A would also be EC-elements. When a SET 
instructions replaces an EC-element in A by a value, this value must be forwarded to the corresponding 
elements in structures which were created by append on A. There may be a cascade of value- 
forwarding precipitated by this since the values may also have to be forwarded to arrays created by 
appends on structures derived from A. Since suspensions are potential sites for EC-queues, append 
operations on arrays containing suspensions introduces a similar need for Value forwarding. This thesis 
adopts a simple alternative to the value- forwarding discipline outlined above. An append instruction is 
executed provided that there are no EC-clcments or suspensions in the array on which the operation is to 
be performed. If there is any EC-clcmcnt in the array then there is no change in the state of the 
machine: the append instruction remains in the set of enabled instructions and will be selected for 
execution at some future time. 
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if /.opcode = APPEND then 
let 
u = /.Opi, 

(arr. A) = //(«), 
(int, /) = (.op2, 
x = /.op3, 

u = new uid from U 
Act', EIST = 

SendToDeslinationiAcl, E1S, u fA , {((Unconditional, rf opnumj, a J 

((unconditional, d n , opnumj, a n )}) 
in 

if |{/ : A(i) € U X {({ecq} X ECQ) U ({SUsp} X SUSP)}| = then 
Act', 
AddToHeap(H, u\ A'), 

ErSr ~ « U FA' k FA» 

else 

Act, 

H, 

EIS 

endif 

endlet 

where A' (J) = A(j) j* i 

= x j= i. 

and where a . is either (ualue, u') or signal. 

SELECT requires two operands - the uid of an array A and an integer /, and in the simplest case 
(the element being accessed is neither an early-completion structure nor a suspension) returns the value 
associated with the element of A that has index /. The behaviour of the interpreter is more complex 
when such is not the case. The state transition is specified below, and the discussion on early- 
completion elements and suspensions follows. The special value est is used for indicating the end of a 
stream. 
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if /.opcode = SELECT then 
let 
u = /.Opl), 

(art, A) = H(u), % (u r (arr, A)) € H 

(int, /) = /.0p2, % i must be an integer 

'= A(i)) 

in 
if / = (w, (ecq, Q) then 

Act, 

AddToHeap(DeleieFromHeap{H, u. (ecq, Q)),u.(eCQ, Q U {(«_., k rj )}))) 
EIS-{(u FA ,k FA )} 
elsif / = (w v „ (SUSp, («', *'))) then 

let Act', EIST = SendResu!t(Act, EIS, u, (unconditional, k\ signal), signal)) 
in 
Act', 

AddToHeap(DeleteFwmHeap(H, u (SUSp, u, k')), u. (eCQ, u PA , k P .)\ 
EIS--{(u FA ,k FA )} 
endlet 
else 
let jc = 
Act', EIS" = 

SendToDestinations(Act, EIS, u fA , {((Unconditional, </ opnumX a,) 

((unconditional, d n , opnumj, a J}) 
in 

Act', 
H, 

EIS- - {(u FA , k FA )} 
endlet 



endif 



where a = either (uaiue, x) or signal. 
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if /.opcode = SET then 
let 
u l = /.Opl, 

(arr, A) = Hiuj, % (u ? (arc, A)) € H 

(int, /) = /.op2, % i must be an integer 

v = /.Op3, % v € Scalars U U 

% where the uids must be of records, arrays, oneofs. 
I = A(i), % , .- ( U (ec<{, Q)) 

Act', EIST = 

SendToDestinationiAct. EIS. u fA . {((unconditional, d v opnumj, a J 

((Unconditional, d n , opnumj, aj}) 
in 

Act', % the new set of activations. 

AddToHeap(DeleteFromHeap(H, u y (CUT, A)), u y (an, A')), 

% the new heap reflects the fact that the ith element 
% of the array with uid u has value v. 
(EIS-{(u FA ,k FA )})UQ 

% The new EIS' includes the instructions whose addresses were in the 
% EC-queue. (u fA , k fA ) is the address of the current instruction, 
% which is removed from the set of enabled instructions. When the value 
% becomes available, this instruction will be added back to the set of enabled 
% instructions. 
endlet 
endif 

where A(f) = A(J), j * i 

= v, ;=/. 

The use of EC-elements in data structures permits the construction of a data structure before the 
values of all the components have been computed. Suspensions allow demand driven computation. A 
suspension is a tagged triple - a tag SUSp, the uid u of some function activation, and / the index of an 
instruction in the activation. The instruction setslsp takes three arguments : an array A, an integer v, 
which is an index of the array, and another integer v, which is the index of an instruction in the 
template of the SETSLSP instruction. SETSLSP sets the Vjth element of the array to a suspension of the 
form (SUSp. u fA . v,) where u yA is the uid of the activation template of the SETSLSP. When a select 
tries to access the element, the suspension is replaced by an EC-queue which contains the address of the 
SEUCI and a signal is sent to the instruction whose address is found in the suspension. The graph is so 
arranged that the arrival of the signal enables the instruction (u j: \\). winch initiates the computation 
of the value of the clement. 
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if /.opcode = SETSLSP then 
let 
u l = Aopl, 

{arc. A) = H(u x l % ( U] , (an, A)) € H 

(int, Vj) = /.op2 % ( V/ must be an integer 

(int. v 2 ) = /.op3 % f v , mu5 t be an integer 

(u , (ecq, = /4(0 % A(i) must be an early-completion queue. 

Act'. EIS' = 

SendToDestinationsiAct. EIS. u FA , {((unconditional, d,, signal), signal) 

((unconditional, d , signal), signal)}) 
in 

if|Q| = Othen 

% put a suspension in the ith element of the structure with uidu. 

Act', r 

AddToHeap(DeIeteFromHeap{H, u (an, A), k (arr. A'))), 
EIS - {(u FA , k FA )} 

where A'(j) = (if; * Vl then A(j) else (SUsp, (« v )) 
else 

% y'usr sew/ a signal to the instruction whose index isv r 
let Act", EIS" = 

SendResu!t(Act\ Els', u FA , (unconditional, v 2 . signal), signal) 

in 
Act", 
H, 

EIS" - i(u fA , k FA )} 
endlet 
endif 
endlet 
endif 

The switch operator is used to implement the conditional graph schema. It takes two operands 
- a value \> x and a boolean b. The condition fields of the destinations of the switch operator must 
have values either true or false. If b is true, then \< x is sent to the destinations which are marked true, 

otherwise they are sent to the destinations marked false. The destinations (true, d ., opnum ) 

(true, d {p , opnum tp ) denote the destinations to which die first operand must be sent if the second 
operand is true; otherwise the first operand is sent to the destinations (false, </_, opnum ), .... (false, 
d fi . upmun fq ). 
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if 

LopCOde = SWITCH then 
let 

u { = /.opl, 

(boot, b) = l.op2, % b must be a boolean value. 

(true, d ir opnum J (true, </ , opnum J, 

(false, d n . opnum ) (false, L, opnum a = /.desUist, 

Act, ElS 1 = Jl JT 

if b then 

SendToDestina(ions{Act, EIS, u pA , {{{dc [V d (V opnum y ), a t] ), ..., 

( ^V d V °P num tp )< V }) 
else 

SendToDestinations(Act, EIS, u fA , {((&„, d fl , opnum A, a A 

«dc rf p„ uw ^), a A}) 

enaii 

in 

4c/'. 

//, 

Eisr - {(^, ^ )} 

endlet 
endif 

The switch-signal operator is very similar. It takes a boolean operand; if the operand has true 
value then it sends signals to the destinations tagged true, otherwise it sends signals to the destinations 
marked false. 

The SIGNAL instruction requires no operands; it becomes enabled when it receives a signal on 
each of the signal arcs incident on it. The result of executing the instruction is a signal which is sent to 
the destinations listed in the dests field of the instruction. The state transition rule for the signal 
instruction is very simple and will not be specified here. 
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if /.Opcode - apply then 
let 

(clsr, O = //(/.opi ), % (u r (CLsr, Q) € H 

«, = /-op2, % r« ? rrec, rj) € // 

F = //(C(FunctionToApplu)); % f M ff n, f» € H, u f = C(f unction To Apply; 
u = a new uid from U, 
/4c/' = AddToAct(Act, u\ F), 
Act", EIST = 
Send Result 
(SendResult 
(SendResult 
(Act', Eis, u, (unconditional, l, opi ), (ualue, M )), % function closure, 
u, (unconditional. 2. op2). (ualue, u 2 )\ % arguments 

u\ (unconditional, 3, opi ), (ualue, /.destlist)) % return link. 

in 

Act", H, EIST - {(u FA , k FA )} 
endlet 
endif. 

The function closure, argument structure and the return link are sent to the first operand of the 
first, second and third instruction in the activation template of the called function. A return 
instruction in the called function will send the result of the function application to the destinations of 

APPLY. 

The Tailapply instruction is used whenever tail-recursive function application is performed. It 
sends the closure, argument structure and the return link to the first operand of the first three 
instructions in the called activation. It then sends a signal to each of its destinations. 
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if /.opcode = TAILAPPLY then 
let 

(Clsr, O = //( /.opl ). % (u r (Clsr. C)) € //, rAe closure 

u 2 = /.op2, % (u y fTec, /{» € //, the arguments 

u } - /.op3. % (u" T (dests, Destinations) € //, fAe refu/vi /i/i/c 

F = //(GFunctionToApplu)). 

% fy, ^fn. ^ € H, ^CffunctionToApplu; 
u = a new uid from U, 
/4c/' = AddToAct(Act, u\ F), 
Act", EIS = 

(SendResull 
(Act', EIS, u. (Unconditional. 1, opl ), (Udlue, i^)), % Junction closure. 
u, (Unconditional, 2. op2). (value, u )). % arguments 
u, (unconditional, 3, opl ), (ualue, wj), % /-erar/i /M. 
^c/'", EIS" = 

SendToDestinaiioniAci. EIS. u FA , {((unconditional, d v signal), signal) 

((unconditional, d n , signal), signal)}) 
in 
Acr.H,EIS"-{(u FA ,k FA )} 
endlet 
endif 

STREAM-TAILAPPLY is another instruction for function application and is used for tail-recursive 
evaluation of streams. It takes three arguments - a function closure which contains the stream 
producer, a record which will contain the next element of the stream, and the argument record. Its 
semantics are very similar to that of tailapply and it sends signals to the desunations listed in its dests 
field. The compilation of functions which generate streams and use this instruction is discussed in 
chapter 5. 

The return instruction is responsible for sending the result of a function activation to the caller. 
It requires two operands - a return link and a value. It constructs the addresses of the instructions 
which arc to receive the result of the function invocation from the return link and sends the value to 
each of those desunations. In addition, it sends signals to those instructions in its own activation whose 
indices appear in the destination list of RETURN. 
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if opcode = return then 
let 

{dc y d y opnum'y) (dc d opnum)} = //(/.opl), 

% the list of destinations to which the value computed 
% by the Junction must be forwarded 
u v = I.op2, % the value to be returned 

Act', EIS, = 

SendToDestinationiAct, EIS, u fA , {((unconditional, rf signal), signal), ..., 
((unconditional, d , sianal), signal)}), 

Act", EIS" = 

SendToDestinationiAct, EIS, u fA , {((unconditional, d y opnum X aX ..., 

((unconditional, d , opnum' ), a)}) 
in p 

Act", 
H, 

EIS' - {(u fA , k FA )} 
endlet 
endif 

The data flow graph of a function is arranged so that RELEASE is the last instruction to be enabled 

and executed in the activation. The effect of the instruction is to remove the activation it belongs to 

from the set of current activations in the system. In a "real" system, this would amount to the release of 

the storage occupied by the activation template to the pool of free storage in the system. 
if opcode = RELEASE then 

DeleteEromAcl(AcUUc-A, FA) 
H, A 

EIS-{(u FA ,k FA )} 

where FA is the activation template associated with u F .. 
endif 



2.5 Summary 

In the preceding section a formal specification of Vim was given by defining its operational 
semantics. A brief description of the functional language VimVal was given, and some example 
programs illustrated some features of the language. Some of the key features of Vim were described 
informally. Next, we developed a formal model of the abstract machine for Vim. An interpreter for 
executing the data flow instructions was defined. The operational semantics of the data flow 
instructions of the machine wore presented. The state transition rules lor operations on early- 
completion structures and suspensions were formalised. 
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defines the operational semantics of U in which (he machine LI is refined to include a model for 
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Chapter Three 
Operational Semantics of Vim with Storage 



The Vim computer system is envisioned to have a hierarchically organized physical storage 
consisting of main-memory and a disk. Information is brought from the disk into the main memory 
upon demand. Since the system has finite main storage, objects are periodically moved from the main 
memory to the disk to create free space in the main store into which objects from the disk are brought 
in. It is desired that the only information brought into the main memory from the disk are those 
required by the computation and no other. 

The address space of the system is governed by the size of the disk. For the purpose of this thesis 
it is assumed that a sufficiently large disk is available, thus avoiding the complications of managing the 
disk space. To facilitate data transfers between the disk and the main store, the address space is divided 
into equal sized pages, where a page is a set of contiguous words in the address space. Objects are 
stored in these pages. If the page size is large, it may be necessary to pack multiple objects in a page to 
reduce internal fragmentation. It is likely that when a page containing an object referenced by the 
computation is brought into main memory, objects which are not required by the computation would 
also be brought in since they share the same page. This conflicts with our stated goal of reading in only 
referenced objects from the disk into the main memory. 

In Vim the basic unit of storage allocation and for disk*-*main store transfer is a chunk. A chunk 
is a small page, and is expected to consist of 24-32 words. Kach chunk has a unique chunk identifier 
(cid). Since the pages are small, it is unnecessary to allocate multiple objects on the same chunk. 
Objects which arc larger than one chunk arc stored in data structures made of chunks. 

The small page size in Vim allows us to allocate at most one object per chunk without causing 
significant wastage of storage space due to internal fragmentation. When an object residing on the disk 
is referenced, onh thai object (or part of the object, if it consists of many chunks) is brought into the 
dink. Since large data structures are composed of main chunks, choice of a suitable data structure 
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organization should permit large amount of sharing of information; this sharing is essential for efficient 
execution of structure operations in an applicative environment. 

In LI we saw that data structures reside on the heap and only the pointers to the structures (their 
uids) are passed among instructions. In this chapter the operational semantics of an extension of the 
model LI is presented. The extended model, called L2, adds the notion of storage to LI - data 
structures (arrays, records and oneofs) are stored in chunks. The storage representation of arrays in 
terms of chunks will be described; the concepts presented may be extended to the storage 
representation of records and oneofs. 

The modelling of arrays as stored values makes it necessary for us to consider the issues of storage 
allocation and reclamation. The unit of storage allocation in L2 is a chunk. For the purpose of this 
thesis it is assumed that there is a large pool of free chunks (which are not part of any data structure). 
The allocation of a storage unit amounts to selecting a cid from this free pool and using the storage 
corresponding to that cid. In L2, chunks which are modelled as being in the main store are tagged 
accessible and the chunks which coorespond to those resident in the disk are tagged inaccessible. 
It is assumed that the free cid selected corresponds to a chunk whose storage part is in the main memory 
(Le. the chunk is tagged accessible). 

A program executing in L2 exhibits dynamically changing storage requirements during the course 
of the computation. This variable demand arises from the fact that data structures are created and 
discarded (in the sense that they are not used any more) during program execution. The storage that is 
discarded can be reused for storing other data structures. 

The function of a storage management scheme in a language implementation is two-fold - 
allocation of memory when the computation demands, and the reclamation of storage which contain the 
values of to discarded information structures. Reclamation of storage and its subsequent recycling 
allows the system to satisfy the storage requirements of the program within the existing bounds of the 
system. c\cn though die total amount of memory (number of free chunks) requested by the 
computation far exceeds the total storage capacity of the system. There arc two principal strategics for 
storage reclamation - the mai k-atid-swecp scheme and the reference-count scheme. 
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Mark and sweep garbage collection is the most common method of automatic storage reclamation. 
In a simple mark and sweep scheme, the size of the inaccessible information occupying the address 
space keeps growing until there is no free storage left, at which point all normal processing is suspended. 
All the units of storage which are in use are marked by tracing down all the structures which are 
accessible from the current state of the system. Then the entire memory is scanned to identify all the 
unmarked storage units - these are the discarded memory units which are aggregrated into the pool of 
free chunks and used for reallocation. A drawback of this strategy is that if the address space is very 
large and the physical store spans disks, the process of garbage collection can be very expensive. Simple 
implementations of mark-and-sweep suspend all computations other than those for reclamation; a large 
number of disk accesses will imply that all other computations will remain suspended for a long time. 
Various algorithms have been proposed which permit concurrent execution of the mark-and-sweep 
reclamation and other computational activities (also known as real-time garbage collection); however, 
they are complicated and exhibit questionable performance in real-life situations. Real-time garbage 
collectors of acceptable performance are difficult to implement even on single-processor systems; how 
the schemes may be extended to perform garbage collection with acceptable efficiency in a 
multiprocessor architecture remains an open problem. 

The notion of using reference counts on the information structures used by the computation has 
been around for a long time; however, there are only a scant number of garbage collectors which use 
reference counts exclusively. The basic idea is very simple. A counter is associated with each 
information unit; it keeps a count of the number of references to the- structure in the system. The 
counter is incremented whenever a new reference is created and decremented when one is destroyed. 
When the count becomes zero, the structure becomes inaccessible from the computation and the storage 
occupied by it may be reclaimed for reallocation. This simple scheme has one major drawback which 
has prevented its use in any practical garbage collector so far - it cannot reclaim circular structures. 
However, it has been shown that memory reclamation using reference counts is possible in the presence 
of certain classes of circular structures [7. 17]. 

Circular stmctures can be created only if there arc operations which cause side-effect. All 
operations in VimVai arc free from side effects and so die user cannot create circular structures. The 
creation of circular structures bv the interpreter (for whatever may be the purpose) has been precluded 
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by design . These features of the Vim system make it feasible to use a reference count mechanism for 
garbage collection. The principal argument against reference counts is that the cost of updating the 
count every time a structure is manipulated may be unacceptably high. A significant advantage of 
reference count mechanism for garbage collection is that storage reclamation is done concurrently with 
the computation. Also, the scheme appears to be more amenable to implementation on a 
multiprocessor architecture. 

In L2, two counts - refcnt and setcnt are associated with each chunk, refcnt contains the 
count of the number of references to the chunk in the current state of the machine. A chunk is 
reclaimed when its refcnt field becomes zero. The refcnt fields of all the structures which are 
pointed at by the chunk whose refcnt field becomes zero are also decremented. The Setcnt field of a 
chunk is used only if it is the root chunk of some structure. It keeps a count of the number of elements 
in the structure which are EC-queues. 

Some simplifications (of "real" life behaviour of computer systems) have been made in 
developing the formal model L2 to reduce the complexity of the model within manageable limits. In a 
"real" system, information which is in main memory is immediately accessible; in L2 the chunks which 
correspond to those resident in the main store are tagged accessible. The chunks which correspond to 
those on the disk are tagged inaccessible. Instructions are tagged executable if they have received 
all their operands and signals. Only such an instruction is chosen for execution. The instruction 
executes ("runs to completion") only if all the chunks that it requires to access are tagged accessible. 
If such is not the case then the system requests that the chunk be made accessible and the instruction is 
tagged dormant. Some other executable instruction is then selected and run for execution. 
Eventually, the requested chunk becomes accessible and the instruction which requested the chunk is 

made executable. 

Data flow graphs usually expose a high degree of concurrency in most programs. It is hoped that 
by using suitable program transformation techniques, the number of enabled instructions at any time 
during the execution of die program will be very large. The overlap between instruction execution and 



' In an implementation for his comhinaior reduction l;Hnuu:iyc. Turner [.57| uses circular structures to model recursion. 
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disk accesses is the principal source of concurrency in the system. I expect that in an actual 
implementation the paging algorithms and instruction scheduling can be so ordered that the system 
seldom has to wait for a disk access to complete before it can execute an instruction. This translates into 
the following caveat - there must be at least one executable instruction during most of the time of the 
program execution. 

3.1 Arrays and ViM-trees 

We now examine a special kind of data structure called a ViM-tree, which is used to store the 
elements of an array in L2. 

A positional k-tree is a directed tree with the following property : Each edge out of a node v is 
associated with one of the numbers in {0, 1, .., k-\}\ different edges, out of v, are associated with 
different numbers. It follows that the number of edges out of a node is at most k, but may be less; in 
fact, a leaf has none. 

We associate with each leaf node v in a positional A-tree V the word consisting of the sequence of 
numbers associated with the edges on the path from the root r to the node v. This sequence is called the 
index word of node v. The index word also represents an integer in base k. The height of the tree is the 
length of longest index word in the tree [15]. 

A Vim -tree is a positional A-tree in which every node is associated with a chunk. The chunk 
associated with the root node is called the root chunk. A chunk has two parts - header and chunkstore. 
The header part of the chunk contains some book-keeping information about the chunk; the chunkstore 
contains the actual data values (or pointers to other chunks). Elements of an array are stored in the 
chunkstore part of some of the chunks associated with the leaf nodes. Those leaf chunks which contain 
elements of the array are called value chunks. All \nluc chunks have index words of the same length. 
For convenience, the terms "value chunk" and "root chunk" will be used in place of "chunk associated 
with the leaf node" and die chunk associated with die root node". A word in the chunkstore of a value 
chunk in a Vm-trec is uniquely identified by die base- A- integer wi. where w is the index word of the 
wiluc chunk and / is die word number in die chunksiorc. I shall use die terminology "the M/lh word in 
the Vim -tree I" to denote die /th word in the chunk with index word ivin I': wi is die word number (in 
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base-&) for that element of the array in V. All the words of the chunkstorc part of a chunk contain the 
value unallocated by default. If an arc from node A to B be marked /, then the /th word of chunk 
associated with A contains the cid of the chunk at B. If there is no node corresponding to the /th edge 
from A. the /th word of A contains the value unallocated. 

Therefcnt field of a chunk is a count of the number of occurrences of the cid of the chunk in the 
current state of the machine. This is used for reference counted automatic storage reclamation. The 
setcnt field of the root chunk contains the number of elements of the array which are currently 
EC-queues. This field is used to determine if an append operation should be performed. The depth 
field of the root chunk has value d, where the height of the tree is d-l. It is used to construct the index 
word to the value chunk. The number of array elements that can be stored in a full ViM-tree of height 
d-l is k*. 

The to and hi fields of the root chunk of ViM-tree V contain the low and high indices of the array 
whose elements are stored in the tree. If the low index of the array is p and the word number for the />th 
element in V is s^s^-s^ then the m min field of the root chunk is (p - Vi^2-Vr> a11 arithmetic 
being done in base-£. The m^ field is used to determine the index word of the Value chunk in which 
the element which is to be accessed resides. 

Let an array A with index bounds p and q be stored in a Vim tree V in which the m and depth. 
fields of the root chunk have values m. and d. For every / within the bounds, (i- m ) is the word 

mm J \ m iw 

number corresponding to the /th element of the array A. The word corresponding to the word number 
wi in V is said to be shared if there is a chunk corresponding to the the index word w, and the refcnt 
field of some chunk along the path from the root determined by the word index has value greater than 
1. Otherwise, the word is unshared. 

3.2 Operational semantics of L2 

In 1.1 wc saw that arrays are represented as abstract mathematical entities - as functions mapping 
integers to salucs. In 1.2 wc augment LI by introducing a storage model for arras s. This chapter 
focuses on the operations on arrays in 1.2. The operations on records and oneofs are \ery similar to 
those on arrays: records and oneofs may be regarded as fixed-length arrays from the point of view of the 
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implementation of their operations in the machine. Functions, activations, early-completions queues, 
etc. are still regarded as abstract mathematical entities. This simplifies the presentation and keeps the 
complexity of the model within reasonable bounds. The techniques illustrated in this thesis may be 
used to develop a model in which the aforesaid entities are also data structures, rather than sets and 
functions. 

The rest of this chapter is a description of the model L2. The notation used is the same as the one 
used in presenting LI. Sets are denoted by bold font, elements of sets are denoted by italicised letters 
and names are written in a special font. Thus, This is a set. This € This and This is a name. 

A State S in L2 is a four-tuple consisting of Act (the current set of function activations), H (the 
heap), EIS (the set of enabled instructions) and C (the set of chunks which are currently in use to store 
the arrays on the heap). 

Vim = <fnterp, State> where 

State = Act X H X EIS X C 

Act = U -+ [N -» Instruction] 

H = U -» [({fn} X Function) U ({ecq} X ECQ) 

U {(instr} X Instruction) U ({destS} X Dests) 
U ({Clsr} X Clsr) U ({an} X Structure] 

Cid = the set of unique names of chunks. 

The functions AddToHeap, DeleteFromHeap, AddToAcl and DeleteFromAct are the same as 
defined in LI. 

A structure is defined by a cid and a collection of chunks which store the values of the elements of 

the structure: the atf corresponds to that of the root chunk of the ViM-tree. 
Structure = Cid X C 

The set of enabled instructions is partitioned into two subsets depending on the tags on the 
instructions. When an instruction first becomes enabled it is tagged executable and added to the set 
of enabled instmctions. lnstmctions with executable tags arc tagged dormant if they attempt to 
access chunks which arc inaccessible, dormant instructions become executable when the chunks 
they were ining to access become accessible. 
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E1S = 9(EI) 

EI = Status X U X N 

Status = {executable} u (dormant x Cid) 

Each chunk has a unique name, a tag, and some storage called chunkstore. There is a unique 

chunkstore associated with each cid. The storage part consists of some header and k words for values. 
C = 9(Chunk) 

Chunk = Cid X {accessible, inaccessible} X Chunkstore 
ChunkStorc = Header X DataPart 
Header = Int 6 

DataPart = (Scalar U U U SUSP U Cid U {unallocated})* 
Both Header and DataPart are sets of ordered tuples. 

The following notation is stricdy adhered to in the rest of the presentation. Ch. always represents 
an element of Chunk, c. denotes the unique name of the chunk Ch. and cs. denotes the chunkstore part 
of the chunk Ch Thus, if Ch w is a chunk, then c is its cid and cs is the chunkstore part of the chunk. 

i n> w w ~ 

c w m mm' C w i °' c *- ni ' c H , ae P th ' c w re f cnt and c^-Setcnt) denote the first six elements of the ordered 
tuple cs w . c^i] denotes the (/+6)th element in the tuple. The notation for drawing a chunk and 
specifying the contents of the chunkstore part is given in figure 9. 

The chunkgraph of an array A in L2 is defined as follows. Let V be the ViM-tree in which the 
elements of the array A are stored. The nodes in the chunk graph correspond to the chunks associated 
with the nodes in V\ if the edge from node A to B in V is marked /, then an arc is drawn from the box 
number /' of the chunk associated with A to the chunk at B. Chunkgraphs are an efficient and concise 
notauonal convenience for specifying the operations on ViM-trees. 

The chunkgraph of a heap is the collection of the chunkgraphs of the structures on the heap. The 
chunkgraph of a heap provides an easy way of indicating the sharing of chunks among structures. 

Scalar values are as defined in LI. 

Scalars = Integers U Reals U Roolcuns U Character U Null 

Integers = {int} X {{uiidcj] U the set of all integers) 

KeaJs = {real} X ({undct} U the set of all reals) 

Moolfiins = | bOOt } X({iriic.f(iix\ undcj}) 

(. haraeter = |Char| X {\unJcj} U the set of characters in die machine.) 

Null = {null} X \ni!.undt'J\ 
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k words of the data part of the chunk. 



k-2 k-l 

The header part of the chunk 



where c l is the cid of the chunk and cs l is the chunkstore part of the chunk. 
Figure 9: Notation for drawing a chunk and specifying its value. The chunkstore part of the chunk is represented by a 
box, which is divided into two rows of boxes. The upper row is divided into six boxes, one corresponding to each of 
m mw- ^ ^ dtpth, SetCnt and refCMt fields of the header part of the chunk, in that order. The second 
row contains the k words of the data part of the chunk. The unique name (cid) of the chunk is indicated at the left of 
the box. An unsigned integer in the TefCYlt or SetCnt field means that the field now has that value. A signed 
integer in the box implies that the new contents of the box is equal to the old contents added to the signed integer. This 
notation will be used to specify how the reference counts on chunks is incremented and decremented. 



ECE = U X N 

ECQ = 3* ECE) 
SUSP = [U X N] 

The definitions of the sets Instruction, Function, ECE, ECQ and Dests are the same as in LI. 

Instruction = OPS X (U U Scalars) 3 X N 2 X U 

Dests = "3(D) 

D = {unconditional, true, false} x N x {opi,op2,op3} 

Clsr = [({FunctionToApplu} UM)-*U] 

where C(FunctionToApplu) € U X ({fn} X Function), C € Clsr 

The function SenJResull which is invoked to dispatch the result of an instruction to the 
destination instructions is almost identical to the one in LI. The only difference between is that in L2 
the instructions which become enabled arc tagged executable: in LI no tagging is done. The function 
ScudTuDcsiiiidiions is the same as in LI. 
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SendResuh : Act X EIS X U X I) X [[{UOlue} X (U U Scalars)] U {Signal}] 

-» Act X EIS 

Define SendResult{Act, EIS, w (dc, i, opnum), result) = 

let 

FA = Acl(u fA ), 
I = FA(i) 
in 

AddToAcl(DeleteFromAct(Act. u FA , FA), u FA , FA') % new set of activations 

if (T.opcnt = 0) A (/-.silent = 0) then EIS u {(executable, « /)} 

else EIS 

endif 

endlet 

where 

FA'(j) = FA(j), j*i. 

= T, j= i. 

and I' € Instruction, 

r.Op\ - if opnum * Opl then /.Opl else /where result = (UOlue, /) 
/\Op2 = if opnum * Op2 then /.0p2 else f where result = (UOlue, /) 
/\0p3 = if opnum * op3 then /.op3 else / where result = (UOlue, /) 
/.opent = \{ opnum € {opl . 0p2, op3} then (/.Opcnt - 1) else /.opent 
f.sigcnt = if opnum = signal then (/.siocnt-l) else Asiocnt 
r.destlist = I.destlist 

endfun. 

The function //j/er/? maps a state and an enabled instruction to a new state. The enabled 
instruction chosen by Choice must have tag executable. 
Interp : State X Choice(ElS) -— State 

where State = Act X H X EIS X C 

A practical implementation of Vim would have a finite amount of main store and a very large 
amount of storage space on the disk. The contents of a chunk cannot be read unless it is present in the 
main memory. Chunks arc read into the main memory from the disk on demand. Eventually there 
may not be any free storage in the main memory into which chunks may be brought in. The system 
frees main storage by moving some chunks from the main memory to die disk and declaring the main 
storage that was occupied by them to be free. New chunks from the disk arc placed in this free storage, 
which is then marked as occupied. Effectively, chunks which arc resident in the disk arc not directly 
accessible to the compulation. Thus chunks become accessible/inaccessible during the execution of a 
program, depending on whether the> mo\c from the disk to main memory, or from main store to disk. 
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Chunks which are modelled as being in the main memory are tagged accessible, otherwise they are 

tagged inaccessible. To capture this notion of chunks becoming inaccessible during program 

execution, a function PageOut is introduced. PageOut selects some chunks in the current state of the 

machine which have tag accessible and marks them as inaccessible. 
PageOut : C— C 

Every element marked dormant in the set EIS € EIS contains a pointer to a chunk (the cid of 

the chunk); the tag on the chunk is inaccessible. Fetch selects some such cid, tags it as accessible 

and all the instructions which had become dormant trying to access this chunk are tagged 

executable. The action performed by Fetch corresponds to the conventional notion of pages being 

brought into the main memory from the disk. 
Fetch : EIS X C -» EIS X C 

Let c be the cid of a chunk which is tagged inaccessible and let W = {(u, k) : (dormant, c, (u, 
*)) € EIS}, W* {}, in some state (Act, H, EIS, Q of the machine. Fetch(EIS, Q returns a new set of 
enabled instructions given by (EIS U {(executable, u, k) : (u, k) € W)) - W, and a new set of 
chunks specified by (C U {c, accessible, a}) - {(c, inaccessible, cs)} where cs is the chunkstore 
associated with the chunk with name c. 

The main loop of the machine is defined by the following tail- recursive function. The machine 
executes an instruction, makes some chunks inaccessible and then makes some of the demanded chunks 
accessible. 
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Define MainLoop (S : Stale) = 
let 

(Act v H v EIS V q) = S 
in 
jf EIS = {} then halt 
else 
let 
e = ChoiceiEIS) where e = (executable, u pA , k fA ), 
EIS, C = Eetch(EIS v PageOuKCJ), 

Act = Acl x 
in 

MainLoop{Interp{Act, H, EIS, Q, e) 
endlet 
endif 
endlet; 

Interp defines the manner in which the state transitions are made, depending on the instruction 
which is being executed. 

Define Interp((Act, H, EIS, Q, e) = 
let 
{status, u, k) — e, 

% The instruction must have tag executable. 
FA = Act(u), 
I = FA(k) 
in 

if /.opcode = iadd then ... 

clsif /.opcode = mkintarray then ... 

elsif /.opcode = apply then ... 

endif, 
endif 
endlet 

The notation 

(Act, H, EIS, O I- (Act'. If, EIS\ C) on e 

denotes that if the state of the machine given by (Act, H. EIS, O is the argument to Ma'ml.uop then 

(Act\ If. EIS". C) is the result of executing the instruction p chosen by Choice, and invoking PagcOut 

and Fetch in sequence. 

We arc now equipped to describe die actions of die interpreter. The scalar operations do not 
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affect the heap and so the C component of the state is unaffected. The state transition rule of the 
instruction is almost identical to that in LI, the only difference being the introduction of the fourth 

component in the state (which remains unchanged). 

if /.opcode - iadd then 
let 

(int, m) = /.opl, 
(int, n) = /.op2, 
sum = m + n, 
Act', EIST = 

SendResu!l( 
SendResult(...( 

SendResult{Act, EIS, (u F4 , (Unconditional, d v opnumj), aj, ... ) ..., 
(u fA , (unconditional, d n , opnumj), a n )) 
in 
Act, 
H, 

Eisr - {(executable, u FA , k FA )}, 
C 
cndlet 
endif 

where a . € {(UOlue, sum), Signal} 

Other scalar operations have very similar state transition rules and do not affect the heap or the set 
of chunks. 

Operations on arrays will now be described. Figures are used to explain the algorithms for 
building and manipulating the trees of chunks that store the contents of the arrays. 

The state resulting from the execution of the mkintarray instruction is described below. 
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if /.opcode = MKINTARRAY then 
let 

(int,p) - I. op), 
(int, q) = /.op2, 
n = .|/.dests|, 

(c r accessible, csj = a new chunk, 
u = a new uid, 

A - (u, (arr, c r {(c v accessible, c^)})), 
^tf, £AS" = 
SendToDestinationiAct, EIS, u fA , {((Unconditional, d v opnum^, c^), ..., 

((unconditional, d n , opnumj, aj}) 
in 
Act', 

AddToHeap{H, u, A), 
Eisr ■ {(executable, UfA , k FA )}, 
C U {(c v accessible, c^)} 
endlet 
endif 

where a . is either (UOlue, u) or Signal. 

As mentioned earlier, it is assumed that an accessible free chunk is available. The contents of the 
chunk with cid q is in figure 10. The contents ef this chunk along with the definition of the SELECT 
operation ensure that any SELECT operation on this tree produces the an undefined value. 
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k words of the data part of the chunk. 

Figure 10: The chunk siructure created by the mmmakuay instaicLion. The entire tree tree of chunks is not created: 
only the root chunk is allocated, lhe symbol UA stands for unallocated. The depth field is sci lo the value d = 
\km k {a- p + l]) 
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Let us now consider the effect of the instruction mkintarrayec on the state of the machine. It 
acquires a collection of chunks which are not members of the set C in the current state of the machine. 

These chunks are used to build a tree which is illustrated in figure 11. 

if /.opcode = mkintarrayec then 
let 
(int./?) = /.opl, 
(int, q) = /.op2, 
n - |/.dests|, 

M = q-p+l, 

N= A/(A: J+1 -1)/((A:-1)^ +1 ), 

{(c v accessible, csj, ..., (c^ accessible, cs N )} = N free accessible chunks, 

u = a new uid, 

A = («, (an, c v {(c v accessible, csj, ..., (c^ accessible, csj})), 

Act', EIS' = 

SendToDestination^Act, EIS, u fA , {((unconditional, d v opnumj, aj, ..., 
((Unconditional, d n , opnum), a^)}) 
in 
Act', 

AddToHeapiH, u. A), 

C U {(c r accessible, csj, ..., (c^ accessible, cs N )} 
endlet 
endif 

where a is either Signal or (ualue, u), the 

contents of the chunks is shown in figure 11 and the resulting 

heap /f is specified by augmenting the chunkgraph of the heap //by 

the chunkgraph shown in figure 11. 

The append operation is by far the most complex operation. It requires three arguments - an 
array, an integer index and a value (uid of some other structure or a scalar value). Recall that the 
append operation creates a new array only if its argument array (first operand) does not have any 
EC-queues; otherwise it is attempted for reexecution at some later dme. In L2 the setcnt field of the 
root chunk of the first operand (which must be an array) contains number of r.c-qucucs in the structure. 
If the setcnt field is not zero, then no change occurs in the suite. Instead, some other instruction is 
selected by the Choice function in the next iteration of Main Loop. The append instruction remains in 
the set of enabled instructions and will be eventually executed, when all the EC-queues have been 
replaced by \alucs by SET instructions. 

If the first operand to append is a shared structure (mam pointers to it exist in the uirrrcnt state 
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figure //: Tree of chunks created by created by mkintarrayec. p and q are the bounds of the array, A/ = q-p+ 1, d 
= | log ^(Mj) and ^ is the number of destinations of the instruction c(mkintarrayec). ecqQ denotes an empty EC-queue. 
Thus all the elements of the array point to empty EC-queues. s.,s.,...s..s ( . is the word number of element with index 
q in the array. The word number of the element with index p isOO.J). 



of the system), then a new array is created which shares a number of chunks with the argument array. If 
the value of the refcnt field of the root chunk of the first operand to append is one, then it is possible 
to perform an in place update. This condition under which no copying need be performed at all to 
implement the append operation can be taken advantage of by the compiler. If the integer index (the 
second operand) is outside the bounds of the argument array, append creates a larger array. The 
transition rules arc specified in the following pages. 

Let the array on which the append instruction is to performed have die chunkgraph shown in 
Figure 12. 
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Figure 12: Chunkgraph of the array on which the append operation is performed. 



if I.opcode = append then 
let 

u x = I. Op), 

(atT, c v {(c v af v csj, ..., (cy, afjf cs N })) = H(uJ, 

(int, /) = /.op2, 

x = /.Op3, 
P = c x iO, 
q = CjJU, 

d= c v depth, 

n - |/.fteStS|, 



in 



u 2 = new uid from U 

if |/ : clement with word index / of the array is a suspension 
or an EC-queue| >0 
then Act. H. FfS. C 
% There are EC -queues in the structure - append does not execute. 
elsif p < i < ^ then 

if (word number (/-c,.m ) in ViM-stnicturc with root <-. is unshared) 

1 mm \ ' 

then ... 
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else ... % The element is shared. 

endif 
clsif c,.m < zXpthen ... 

1 mm r 

elsif i< c,.m then ... 

1 mm j 

elsif q< i<c,.m + k a then... 

1 mm j 

else ... % i>c r m min + IT... 

endif 
endlet 
endif 

First consider the case in which the z'th element of the array is not shared among any other 
structures. The append instruction performs an in place update by replacing the value of the z'th 
element of the array by the new value x. The ViM-tree represents a new array, which is reflected by the 
new uid that is associated with the structure. The set of chunks C remains unchanged from the previous 
state. 

If any chunk with cid c whose contents need to be accessed during the execution of the append 
instruction is found to have an inaccessible tag, the state S f = (AcU //,, EIS f , C) resulting from 

the execution of the append instruction is defined below. 

Act f = Act 
H/= H 

E7S f = (Eis u {((dormant, c), u FA , k FA )} - {(executable, u FA , k FA )} 

The instruction thus remains in the set of enabled instructions. Eventually when the chunk c 
becomes accessible (caused by the function Fetch), it will again become executable. 

The actions of the interpreter for the append operation will now be presented. Consider first the 
case when the zth element of the array on which the append is performed is an unshared element and 
z'th lies within the bounds of the array 6 . 



A simplituiiu assumption made here is (hat there is a leaf chunk corresponding to the iih element of the array. If that is not 
the case then neu chunks arc added to the set of chunks in the state and the set C is augmented suitably. 
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'f P < ' < Q an ^ (word number (Z-c^TH. . ) in ViM-structure with root c l is unshared) 
then 
let 
Act', EIST = 
SendResult{ 
SendResult(...( 

SendResult(Act, EIS, (u fA , (Unconditional, d y opnumj), a J, ... ) ..., 
{u fA , (Unconditional, d opnumj), a )) 
in 
Act', 

(H-(u r (arr, c v {(c v accessible, csj, ..., (c^ accessible, cs N )}))) 

U {(«,, (arr, c v {(c r accessible, csj, ..., (c^ accessible, cs N }))} 
Els' - {(executable, u FA , k FA )}, 

C where C reflects the fact that an in situ change has been made to the chunks of 
the structure A as shown in figure 13. 
cndlet 
endif 
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/■inure 13: Chunkiiraph of the result of APPrsn on the array shown in figure 12 when p < / < 4 and the element is 

an unshared clement {M = Oand n - 1). 



Now consider the case in which the clement is shared among structures on die heap. A new 
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structure is created by copying chunks along the access path. The reference count of the argument 
structure A is decremented by 1. If A.refcnt becomes zero, the node is deleted from the heap and the 
reference counts of all the chunks that c x points at are also decremented. This may cause a cascade of 
deletion of nodes from the heap. If any of the chunks whose contents needs to be accessed (for 
decrementing its reference count field or for reading the contents of its chunkstore) is tagged 
inaccessible then the instruction is made dormant and no changes are made to the Act, H and C 

components of the state. The state transition rule for such a case has already been described. 

if P < ' < 1 and (word number (/-c 1 .m ff|/n ) in ViM-structure with root c 1 is shared) 
then 
let 
Acl\ EIST = 
SendResult( 
SendResult(...( 
SendResult(Act, EIS, (u fr (Unconditional, d v opnumj), aj, ... ) ..., 

(u F4 , (unconditional, d n , opnum )), a )), 
(c\, accessible, cs\), -Ac'^. accessible, cs") = newdiunks unused in C, 
If = H U {«,, (art, c r {chunks shared between argument and result arrays} 
U{(c' p accessible, cs\), ..., (c'^ accessible, cs' N )} 
- {structures whose root chunk has refent field has value zero} 
in 
Act', 
IT, 

Eisr - {executable, u FA , k FA )}, 
C u {(c\, accessible, cs\), ..., (c^ accessible, cs N )} 
■ {chunks whose refent field becomes zero} 
endlet 
endif 

Now consider the case in which A.m. . < / < Aio. The resulting Vim structure is of the same 

mm ° 

height as the old structure. New chunks are acquired from the pool of free chunks and are initialized 
such that much of the information common to the two arrays is shared on chunks. A.refcnt is 
decremented: if it becomes zero then A is deleted from the heap, as arc structures whose reference 
count becomes zero. The chunks in which die elements of the structures arc stored arc deleted from C 
if their refent field becomes zero. It is easily seen that the result structure A" preserves the semantics 
of the append operation - a SELECT done on A" on 1.2 maps to the same value as a SIT ECT on the result 
of M'Pi ND(/I. /, .Oin 1-1. 

'ITic third case arises when c, < i< <■ lo. The resulting tree has the same height as the argument 
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Figure 14: Chunkgraph produced by append on the /th element of the structure whose chunkgraph is shown in figure 
12. This is the case when p < i < qand the element is a shared element 



tree. Chunks along the access path are copied, while others are shared as shown in figure 16. The to 
field of the root chunk of the Vim -tree for the result array is set to /. No change is made to the value 
represented by the argument structure. The refent field of c } is decremented. If that becomes zero, 
then the usual process of decrementing reference counts is started. The deletion of structures must be 
reflected in the resulting heap and set of chunks in the state. 
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if c,.m . < Ko then 

1 mm r 

let 

Act, EIST = ... 
in 

cndlet 
endif 



The action of the interpreter on this occasion is similar to that in the previous cases. See figure 16 for 
the chunkgraph of the part of the heap which is affected. 
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Figure 15: Chunkeraph for result of am-ind when f,.ITl . <i<p. 

1 mm y 



61 



62 OPERATIONAL SEMANTICS OF VIM WITH STORAGE §3.2 

Now wc consider the case in which the height of the Vim- tree resulting from the append on A is 
greater than the ViM-tree for A. This happens when /'< A.m . The Vim -tree for the result array A' 
created by append is of the minimum such height that A'.m < ;', and SELECT^, A.m. .) = 
SELECT(/f, A.m mjn ). The semantics of the APPEND operation (as specified in LI) is preserved; a formal 
proof of this assertion will be presented in the next chapter. The reference count of A does not change 
since one reference to it is consumed by append while a new one is inserted in A'. 

Given / < c r YY\. mjn , a tree of the minimum possible height must be constructed such that if c' be 
the root of the resulting tree then i-c r m . > 0. The appropriate height can be computed as follows. 

Let d be the height of the resulting tree, which is shown in figure 17. Clearly, the word number of 

fj.in in this tree is 100.. .00 such the length of the sequence is d. 
.'.c,.m . -c\.m . = 100..00 

1 mm 1 mm 

=*> c\m. = c v m. - (100...00), in base k 

l mm i mm x j -\ 

so that c',.m . = c,.m . - fr' 1 . 

I mm I mm 

Now, i-c\.m . >0 
1 mm —f , 

=* i-c r m mm + ^ _1 >o 
=> k d ' i >c,m . -i 

— 1 mm 

=*d-l>\og k (c r m mm -0 
=*d>\og k (c r m m . n -i) + i 
^d = \\og k (c l m m . n -i)] + l. 

It is of interest to note that the word number of c, .m . could also be ss000...00, where Ks<k. 

1 mm — — 

The arithmetic would be vary similar to the above case. 

The instruction becomes dormant if any of the required chunks is tagged inaccessible. The 
refcnt field of the argument array need not be decremented because even though the instruction 
consumes a reference to athe array, a new one is created in the new structure. Therefore, in this case no 
storage reclamation will be triggered. 
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if/<c,.Tn then 

1 mm 

let 

Act, E1ST = ... 
in 

endlet 
endif 

see figure 17. 

The cases for the rest of the two cases are similar to the previous two cases and are not discussed. 

The state transition rule for the select operation is specified below. The select operation 
decrements the reference count of the argument structure. If the element which is being accessed by 
select is an EC-queue then the address of select is placed on the EC-queue and the instruction is 
removed from EIS. If the element is a suspension then the suspension is replaced by an EC-queue 
containing the address of select and a signal is sent to the instruction whose address was specified in 
the suspension. If the element is a scalar value then the value is simply dispatched to the destinations. 
If the result of select is a structure, then its refcnt field is incremented by n, the number of 
destinations of select. If Arefcnt becomes zero due to the decrementing of the reference count it is 
deleted from the heap. The refcnt fields of the chunks that the root chunk c, of A points at are also 
decremented and the chunk c x reclaimed. The decrementing of refcnt fields may trigger more 
reclamation. If any of the chunks which needs to be accessed is tagged inaccessible then select is 
made dormant; no changes are made to the Act, H and C components of the state. 
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if /.opcode = select then 
let 

u 1 = /.Opl, 

(an, c v {(c v af v csj, .... (c^ afp cs N })) = //((Kj), 

(int, /) = /.op2, 

in 
if (/ < c r lO) or (/ > ^Jli) then undef 
else 
let 

jt = contents of word number (/ - c,.m . ) in the ViM-tree with root c, 

v 1 mm' 1 

in 

if x is a scalar then ... 

elsif x is a uid u B corresponding to structure B then ... 
% send the value and increment ref cnt 
% field of the root chunk of the Vm-tree for B. 
elsif x is an EC-queue then add (u FA , k FA ) to the queue, etc. 
elsif jc is a suspension then [replace suspension by EC-queue with (u f .., k f X 

increment ^.Setcnt, decrement c.Tefcnt, etc.] 
endif 
endlet 
endif 
endlet 
endif 

Observe that if c^refent becomes zero after SELECT executes, the node corresponding to the uid 
u 1 is deleted from the resulting heap and the refent fields of all the structures that it points to are 
decremented. If any chunk required by select (either for accessing the element or for updating the 
refent fields) is tagged inaccessible, the instruction is made dormant, thus changing EIS; the other 
components of the state remain unaffected. When the chunk becomes accessible later, the select 
instruction becomes executable. 

The transition rule for set is given below. 
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if /.opcode = set then 
let 
(u { = /.Opt, 

(an, c v {(c v af v cs x \ .... ( Cn . af„ « })) = //(«), 
(int, /) = /.op2, 
x = /.op3 
in 

if the (i-c r m mjn )th word of the ViM-trec with root c, is an EC-queue Q then 
let 
Act', Els' = send signals to destinations of e, 
EIS" = £75' u {(executable, u, k') : (u\ k') € <?}, 
AT = the old H plus the change in the contents of the chunk of A is reflected, 
C = same as C except that the chunk containing the EC-queue contains x 
and decrement refent and setcnt fields of c, 
in 

Act', IT, EIS", C 
endlet 
else 
let 

Act', Els' = send signals to destinations of e 
in 
Act', 
H, 

Els', 
C 
endlet 
endif 
endlet 
endif 

The transition rule for setsusp is defined as follows. 
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if /.opcode - setsusp then 
let 

(u v (arr, c v {(c v af v Wl ) (c^ af^ cs N })) = l.op\, 

(int, o = /.op2, 
(int, ™) = /.op3 
in 
if word number (i-c r m ^ in VlM-tree with root c, is an empty EC-queue then 
let 
Act', Els' — send signals to destinations of e, 
hF = reflect the fact that the rth element of the array is a suspension 
and the EC-queue at the element is deleted from heap 
and elements deleted from heap due to refent becoming zero 
C = different from C in that the chunk containing the ith element 

now contains a suspension and decrement refent field of c, 
in 
Act, 
IT 

Eisr, 
c 

endlet 
elsif the element is an non-empty EC-queue then 

let 
Act', Els' = send signals to destinations of e' and to (u R ,., m), 
C = decrement refent fields of Cj and reclaim, if applicable, 
IT = Reflect the changes due to changes in C and due to reclamation 

in 
Act, IT, Els', C 

endlet 
else 

let 
Act, FAS' = send signals to destinations of e', 
C = decrement refent fields of c, and reclaim, if applicable, 
IT = Reflect the changes due to changes in C and due to reclamation 

in 
Act, FT, E/5T, C 

endlet 

cmHf 
endlet 
endif 

The set of instructions related to function application (apply. TailaPPLY. strlam-taii.apply, 
RETURN) also do not affect the heap or the set of chunks and their transition rules may thus be directly 
adapted from LI. 
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3.3 Discussion 

The problem of efficiently implementing data structures in functional languages is of long 
standing. Various solutions have been proposed by researchers so that append type operations can be 
done on such aggregrates of values without copying the entire array. 

I-structures proposed by Arvind are write-once structures. I-structures solves the problem of 
read-before write synchronization in a concurrent system; however, the implementation described 
causes the structure to be copied when an append operation is done on it. 

Myers proposed an implementation of applicative lists on AVL-trees [30]. The paper describes a 
generalization of an AVL-tree, called an AVL-dag, which is used as a representation for linear lists. He 
presents algorithms which oerform applicative manipulation of linear lists in time that is proportional to 
the logarithm of the length of the list. He also gives algorithms that perform select and append 
operations on fixed sized arrays with N elements in time 0(KN 1/K ), where Kcan be chosen arbitrarily. 

Hudak and Bloss [21] have recently proposed schemes for statically inferring situations in which 
an append may be implemented as place updates. Failing this, they propose that reference counts be 
maintained on the structures; the entire structure is copied if an append occurs on a structure with its 
reference count greater than one. 

None of the above solutions satisfactorily address the issue of sharing information among 
structures. The new data structure ViM-tree proposed in this thesis allows append and select 
operations to be performed in logarithmic time. Moreover, the algorithms common information to be 
shared among structures, so that the storage requirements of programs is reduced significantly. The 
following factors influenced the design of the data structure for representing arrays : sharing, fast 
select and append operations, and the constraint that the storage has a physical hierarchy. R-trecs and 
A VI. -trees were considered candidates for representing arrays; however, analysis indicated that the 
amount of processing required to balance the trees is substantially more than that for VlM-trces. It was 
found that balancing a &-way AVL-tree or B-trcc would require a larger number of chunks (than for a 
ViM-trcc) to be accessed, many of which might not be in the main memory. It was desirable to keep the 
branching factor of the trees quite high so that the depth of the tree thai had to lie traversed to perform 
the frequent Sl-i I CT operations would be quite low. For example, an array of 4096 elements can be 
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stored in a 16-way ViM-trce of height three. The use of trees of chunks to store data structures also 
eliminates the problem of compaction. 

This chapter also described a reference count mechanism which is used for reclamation of chunks. 
Reference counting permits real-time garbage collection in Vim. The operational semantics of the 
instructions are defined such that if a chunk required to be accessed by an instruction is not in the main 
memory, then the instruction is not executed. In a more detailed model, it may be possible (and maybe 
worthwhile in an actual implementation) to consider partial execution of instructions, so that an 
instruction is removed from the set of enabled instructions once it has been chosen for execution by the 
scheduler. 
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Chapter Four 
Equivalence of LI and L2 



In chapter 2 the operational semantics of LI was presented. LI was then refined to model 
hierarchical physical stoge consisting of main memory and disk and a representation for data structures 
of the storage model was described in Chapter 3. As mentioned earlier, LI provides the specification 
for any implementation of an archicture for Vim. We desire that programs executed on LI produce the 
same result as that produced by running the program on L2, and vice versa. This would demonstrate 
that L2 indeed satisfies the specifications of LI. A formal proof of the equivalence of LI and L2 is 
presented in this chapter. 

Let P be a program written in the base language. Let Translate^ translate a program in the base 
language to some initial state for LI. Similarly, Translate^ produces an initial state in L2 for a program 
in the base language. 

The heap of LI is a directed, acyclic graph in which the nodes are the arrays, closures, etcc, and an 
arc between two nodes in the graph denotes that one structure is a component of the other. We want to 
capture concept of a node in the heap being accessible (not to be confused with tags accessible) from 
the current State of the computation. If the node is not accessible then the structure associated with the 
node is not usable, and is garbage. 

Definition 4-1: Let S - (Act, H, E1S) be a state of machine LI. A node on H in S is 
reachable if one of the following two conditions are satisfied: 

1. There is some unexecuted instruction in Act which has a pointer to the 
node (holds the uid of the node), or 

2. It is a component of some structure on //, and the node corresponding to 
that structure is reachable in S. 

The preceding chapter gave an informal definition of the chunkgraph of a heap. Thcchunkgraph 
of a heap in some state is now formally defined in graph-theoretic terms. 

Definition 4-2: Let .V = {Act'. //". /7.V. (") € Slate in 1.2. let C = {Ch } . Ch 2 

Cli }. where Ch is of die form (c. of. cs) and af is either accessible or inaccessible. 
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The chunkgraph of H in S is a graph (7 = (K E) where P 7 = {C^, Ch 2 ChJ and £" = 

{(c, c\) : (3/7 € {0, 1 £-1}) c\j)} - c }. Recall that the c[m] denotes the contents of the 

with word in the chunkstore part of the chunk whose cidis c. 

It is possible that two different states in L2 represent the same set of values, the only difference 
being that the set of chunks used to store the elements of arrays in the two states are different. Two 
such states are said to be similar, the formal definition of the similar relation is given below. 

Define two functions SlValue l and StValue 2 for LI and L2, respectively, as follows. If u be a uid 
and H be a heap in some state in LI then StValue^u, H) returns an ordered set; the elements of the set 
are the results of select operations done on the array associated with u, SELECT being performed for all 
integer indices. If there is no structure in LI with uid u, the result of StValue^u, H) is the null set 

StValue 2 is also defined in the same manner, except that the heap must be in some state in L2. 

Definition 4-3: Let S y S 2 € State in L2, where S = (Act., H EIS C) and 5, = 
(Act 2 , H T EIS 2 , C 2 ). 

S, and S 2 are similar if 

1. Act x = Act 2 

2. Vm € U [StValuep, HJ = StValue 2 («, HJ] 

3. (V«C UXVfc € A0(Vs € Status) [(«, *, s) € EIS, => [(3s' € Status) : (u, k, 
s') € EIS 2 ]\ 

4. The chunkgraphs for H x in S 1 and H 2 in S 2 are isomorphic. 

The last condition simply indicates that in two similar states the chunks exhibit the same sharing 
relationships, except that the chunkids are different. 

It is easily seen that the similar relation is an equivalence relation, and the set of similar states 
constitutes an equivalence class. 



4.1 Proof of Equivalence of LI and L2 

Informally, two machines arc equivalent if they produce identical results for a given program. 
Moreover, there is a correspondence between computational states that each machine goes through. 
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We shall use an adaptation of the McGowan mapping technique for proving the equivalence of 
two machines [25]. A similar technique was used by Berry [6] to prove the equivalence of two 
information structure models of block structured languages. 

Let P be a program in the base language. Schematically, the computation of P on LI and L2 is 
shown in the Figure 18. A computation is a sequence of states starting with some initial state; if the 
computation terminates, then the final state contains the result. Translate ^P) produces an initial state 
for the program P on the machine M. S n is the final state of LI on computation of P and 
ResultValue^SJ prints the value of the node on the heap which contains the result of the 
computation. Let S Q be some initial state of machine LI. The computation of the machine LI starting 
at the initial S Q is denoted by MainLoop L1 (S Q ). Function FinaKMainLoop^SJ) gives the final state of 
the machine in a computation, if it halts. Similar notation is used for the machine L2. In the following 
discussion, rule definitions which have the same name in both LI and L2 are distinguished by 
subscripted LI or L2. 



Translate 



Program P 



Translate 




Result Value 



Li 



Result Value 



U 



Figure 17: McGowan mapping of states of LI and 1.2. 



The mappings <p and p provide a map between the states of the machines LI and L2 on the 
computation P. To show that LI and L2 arc equivalent for programs in the base language, it suffices to 

construct mappings <p and p 

V.S" <p : y -» s 
V.V p :i'Hi" 
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where 5" € State^ and S € State L1 such that for all programs P in the base language the following 
holds : 

Let S Q = Translate Ll (P) and S" = Translate L2 (P). MainLoop L1 (S ) produces in succession the 
states 5 Q , S v ... and MainLoop L1 (S ^ produces in succession S Q , S\, ... 

Then 

i. p(s q ) = sr 

2.Up(S) = ST i and 5. * Final( MainLoop u (SJ) then p(S j+1 ) = S j+r 
If tpi^) = Sand ST. * Final(MainLoop u (S^) then <pCS" /+1 ) = S. + r 

3. If S^ = Final(MainLoop Ll (S^i) then p(5' /| ) = Fina!(MainLoop L1 (S' q)) 

If 5" n = Final(MainLoop L1 (S' )) then <p(5" ) = FinaliMainLoop^ASJ) 

4.ResultValue u (S' n ) = ResultValue Ll (<p(S n )) and ResultValue^S J = 
ResuIiVa!ue u (p(S n )) where ^ = Final(MainLoop u (S ^) and 5^ = 
Fma/(A/a/«Loo/J.,(5' )) 

Theorem 4-4: LI is equivalent to L2 for the base language. 

Proof: We exhibit McGowan mappings <p and p to prove the equivalence. <p maps a 
state 5" of L2 to a corresponding state S of LI, and p maps a state 5 of LI to a corresponding 
state 5" of L2. 

First we describe mapping <p(S) = S. 

Let 5" = (Act', H, EIS*, C). 

1. Construct Act = Act'. 

2. Construct H as follows. Let V ^ = {u : u is the uid of node on IT}. 

V u £ t/ 7/ . [if /f(w) € Structure then (u. A) € H such that A € Array and 
Si Value ^ : (u.H) = St Value l2 {u. If) 
otherwise (u, tT(u)) € //] 

Clearly, if the reference counting is done correctly, then the following holds : V u 
\{i : 3u'{u'\ X \axr} X Array € //and SiliCKw". /) = w}| = /l.refcnt where 
(CUT, A) = H\u) and A = (u. <-,, {(c,. <7/j, «,) (c^ af N , cs N )\). 

3. Construct 1'IS as follows. 

/:7.V = {(«. A) : (Status X {(w. *)}) € /f/i"} 
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Secondly, we describe the mapping p : S -+ Y such that Y = p(S). 
Let 5 = (/k/, //, fYS). 

1. Construct Act' = Act 

2. Construct If as follows. 

let U R = { u : u is the uid of a reachable node in H) 

For u € f/p, if « is the uid of an array then (u, c y {(c p af v csj, ..., (c^ 
afp cs N )}) € If such that StValue n (u, If) = SlValue u (u, H). Also, 
c r refcnt = (The number of occurrences of the uid u in unexecuted 
instructions of Act or in reachable nodes in H) and CySetcnt = (The 
number of suspensions or EC-queues in the structure with uid u). 

If u is not the uid of an array (or record or oneof) then (u, H(u) € If. 

3. EIST = {(executable, «, k) : (u, k) € £"751 

4. C = {(c, af, cs) : (3u 3c x 3C : (u, c y C)eif and (c, o/ «) € Q}- 
Observe that Y is a member of an equivalence class under the similar relation. 
Thirdly, we show that <p and p meet the requisite conditions. 

Condition 1 : 

If 9(^0^ ~ ^0 ^ en P^q) = 5"' where 5" is a member of an equivalence class under the 
similar relation. Also, cp^'g) = S Q . By judicious of chunks, we can obtain p(S^) = S'q. 

Condition 2 : 

If 9(6" ) = S and S". is not a final state then cpCSV ,) = 5\ ,. We shall consider each 

' ' ' '1+11+1 

instruction and show that the maps hold after the execution of the instruction provided the 

map was correct prior to the execution of the instruction. 

Let e = (executable, u, k) € EIS 1 , which is executed. Assume that all the chunks needed 
by lnterp { , during the execution of e arc tagged accessible by some omniscient Fetch and 
I'ageOut functions. Essentially, we arc ensuring that an instruction in L2 docs not become 
dormant during execution. (Wc shall later sec that this assumption places no restriction on 
the generality of the result). 

For case of exposition, define three functions <p A f <p E]S and <p„such that 9(6") = <p((Act\ 
If, EIS')) = (<p Acl (Acf), <p ,///"), <p ns (EIS')). 

1. Scalar instructions : 
The result of the instruction is sent to instructions in Act' ., the resulting activation 
being Act' ,. 
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The same set of instructions in Act . receive the result of the scalar instruction in LI, 
to produce Act. + r 

The actions of SendResult, . and SendResult. , on Act. and Act', is the same, as is 

Ll L2 i i ' 

easily seen by looking at their definitions. Therefore 
^c/^+i) = Ac ' i+ l 

EIST. + } = (EIST. - {<?'}) U {(executable, «, k) : (m, *) is a destination of 4 
and /.opent = and /.Sigcnt = 0}, where / = (Act'fu))(k)}. 

Also, EIS. + l = (EIS j - {e}) U {(u, k) : (u, k) is a destination of 4 and /.Opcnt 
= and /.Sigcnt = 0}, where / = (Act£u))(k). 

Since <p £I ^EIS) = EIS /it is clear that <p EI ^EIS i+ x ) = ^5. + 1 . 

The heap is unaffected. Therefore ff. + 1 = #\and H. + l = H. Since y^W) = 
//, it is obvious that <P#(tf' ;+1 ) = #- + i- 

Thus for scalar instructions the map <p holds. 

2. append instruction 
By the same reasoning as used for scalars, in the state produced by APPEND, 
VAcf Act 'i+\> = ^/. + 1 , under the stated preconditions. 

We have cp^ = H. We will look at the different cases that arise during the 
execution of APPEND. 

Let Kj be the uid of the array A; u l is the first argument to append. 

a. Number of EC-elements or suspensions in the array > : EIS . = Els' . 
in L2. 

By precondition and the definition of <p and p, in Ll, this corresponds to 
the case that |{/ : element /of A in H. is a suspension or an EC-queue} | > 1. 
Therefore EfS j+l = EIS. Therefore q> £J ^ ElS' i+] ) = EIS. + r 

The heap is unaffected since the instaiction does not execute. Thus 

Therefore <p holds for this case of append. 

b. No suspensions or IC-elcmcnts and AjefCYit = 1. 

As before, <p Act iAcf i+l ) = Acl j+l and <P m </:7<f /+] ) = ElS j+y 

After 4 executes. A is deleted and is absent in /T .: a new array is placed 

it l ' 

on ff All structures which were pointed at by A have their refCYit 

field decremented. If they are pointed at onlj by A then their refent will 
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become zero and they will be absent in FT . ,, 

i+l 

Since qp^, = S. and A.refcnt = 1, A must be reachable from H. only 
from e. therefore, after e executes, A is no longer reachable in the new 
heap H j+ 1 and a new heap is added to this heap for the new array. All 
nodes in H. which were reachable only through A will also become 
unreachbale in H ,. 

Therefore under the given preconditions, 9 / /^' +1 ) = H. ,. 

Thus, <p(5" /+1 ) = S. +1 for this case of append. 

c. No suspensions or EC-elements and A.refcnt > 1 

As in the previous case, <P Acl {Act\ +l = Act. + l and <p EI J.EISr i+1 ) = 
EIS l+r 

After e executes, A remains on the heap since its refent field does not 
become zero. A new array is added to the heap ff . , and the value of its 
tefent field is equal to the number of destination instructions of e\ 

Since P//^-) = H f A is pointed at by many objects in the current State, 
and is reachable from more than one instruction or reachable structure. 
After e executes, A becomes unreachable in H. , through e. However, A 
remains reachable on the heap. 

Therefore, given that <p(S\) =S p we have <p // (tf , , +1 ) = H. +l for this case 

Of APPEND. 

This finally yields <p(5" ;+1 ) = S. + l for the append instruction under the 
given preconditions. 

3. SELECT instruction 
Let A and j be the first and second operands of select, respectively. We shall 
prove that cp holds for SELECT by considering the various cases that arise during 
the execution of SELECT. 

a. Klemcnt being accessed is not FC-cmeue or suspension : By reasoning as 
for scalars. <P A JAcf. + J = Acr +l and q> m U:iS' i+l ) = EIS. + V 

In L2, if the result of select is a structure B then Biefcnt - n, the 
number of destinations of e. If A.refcnt - 1 then A is deleted from 
tf i+v If A is deleted from the resulting heap, the refent fields of the 
structures it points to must also be decremented. 



In 1.1, if die result of the instruction is a astructure B, it is reachable in 
// /f] from the instructions which are the destinations of c. If A were 
reachable only through c then it becomes reachableunrcachahlc in H. ,, 
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as doo all structures which were reachable only through A in H. 

Thus we get that <P//^ (+1 ) = # +1 showing that <p(S". ,) = S. + 1 for 
this case of select. 

b. Element being accessed is an EC-queue 
EIS'. + l = EIST.-{e}. 

Also, the execution of e in LI yields EIS. , = EIS. - {e}. 

Since <P EI ^EIS') = EIS p it is obvious that <P EI ^EISr i+1 ) = EIS j+r 

Act\ +1 = Act, = Act, = Act. + 1 so that <p Act {Act' , + l ) = Act. +y 

On executing e\ the heap f? j+1 is the same as ff . except that the 
EC-queue has an additional element (u, k). On executing e in LI, the 
resulting heap H. +1 is the same as H. except that the EC-queue has an 
additional element (u, k). 

Since T^^P = H r clearly it is the case that 9 // (W /+1 ) = H. v 

Therefore, under the given preconditions, <p(S\ +1 ) = S. + 1 for this case of 

SELECT. 

c. The element is a suspension 

The execution of e in L2 causes its removal from ElS'^y A signal is sent 
to the suspended instruction whose address is found in the suspension, 
which may become enabled. 

The actions of LI are the same so that (pgjJEIS'. J = EIS. + l and 
VAj Act ' i+ J = Act i + i since *<SV = s r 

In L2, if the z'th element is a non-empty EC-queue then (u, k) is added to 
the EC-queue and this change is refelccted in the heap tf. r The same 
actions accur in LI to yield H. . . 

In L2, if the ;th element is an empty EC-queue then it is replaced by an 
EC -queue containing only (u, k) and the nc-qucue is added to the heap 
//" /+r The same action occurs in LI. 

Therefore, given that <p / /W / ) = H, it is the case that Vjf.W /+1 ) = H y 

Therefore, given the <p(.V.) = .V /f , and S\ is not a final suite. <p(i" /+1 ) = .V / + 1 
after the Sii icr instruction is executed. 

4. sit instruction 

Let u, be tlic uid of the array A which is the first argument of sir. and let /'and x 
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be the second and third operands. 

Signals are sent to the destinations of e\ producing Act' . ,. In LI, signals are set 
to the corresponding destinations of e in Act , yielding Act ,. 

Since <P Acl (Act'^ = Act r we get <P Act (Act' j+] ) = Act. + 1 after SET executes. 

After e executes it is removed from £75\ +r The addresses of the instructions in 
the EC-queue for the z'th element of A are added to the set of enabled instructions. 
The instructions which receive signal from set and thus become enabled are added 
to the enabled instruction set, too, to yield £7S" /+r The corresponding actions 
occur in LI; if (u\ k') is an entry in the EC-queue then (executable, u\ k') is 
added to the set of enabled instructions in LI. 

Therefore, given that y^EIST) = EIS p we get <p E1 ^EISr. + 1 ) = EIS. + V 

The heaps are affected in the following way. The EC-queue at the z'th element A is 
replaced by x. If the z'th element is an EC-queue then decrement ASetcnt. 

The corresponding actions occur in LI with heap H. The EC-queue at the zth 
element of A becomes unreachable in H y A now has one less EC-queue, if the 
z'th element was an EC-queue. 

Therefore, given that V^tf) = H.we get<p // (//'. + 1 ) = H. + r 

Therefore, given the condition that 9(6"^ = S and S' . is not the final state, 
< P( 5 ", + J = S j+ 1 for the set instruction. 

5. setsusp instruction 
Let the three arguments to the instruction be n, , z and m. Let u, be the uid of the 
array A. 

After e executes, it disappears from EI5> y If the z'th element of A is not an 
empty EC-queue then a signal is sent to the destination instruction (u, m). 
Corresponding action occurs in LI. Also, signals are sent to the destinations of e' 
and c in L2 and LI, respectively. Thus the corresponding set of instructions get 
enabled in the two machines. 

.'. (pi^ ) = S. implies that after setsusp executes (p rt JEJS'^,) = EIS ^, and 

',* A/o 1+ 1 l-r I 

If die /th clement of A is an empty i-:c-qucuc, then it is replaced by a suspension. 
The rc-queuc is deleted from the heap /f y The same is done in LI to produce 

the heap H ,. 

r 1+ 1 

If the z'th clement of A is a non-emptv EC-queue then //' . and //. , arc identical 
to //"and H . respectively. 
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Thus for both cases, given that cp^ff) = <p. we conclude that <pJff. ,) = 

", + !• 

From the above analysis we conclude that given <p~ = S. and 5". is not the final 
state, <p(-S" /+1 ) = S i+l for the set instruction. ' 

6. mkintarray and mkintarrayec instructions 
After e executes it disappears from EIS . ,. The uid of the result of the 
instruction (or a signal) is sent to the destinations of e, which may then become 
enabled and so would be added to the set of enabled instructions to yield Els'. ,. 
Corresponding actions are performed by the LI machine. . ' . given that <p(S" .) = 
S f we conclude that <P EI ^EISr. + 1 ) = EIS j+1 and <P Act (Act' i+l ) = Act. +V 

Suppose the instruction is mkintarray. The execution of e causes a new node 
corresponding to an array to be added to the heap H* . r Any SELECT operation 
on the array produces an undefined value. In LI, a new node is added to the heap 
coresponding to an array due to the execution of e. Recall that in LI an array is 
represented as a function mapping indices to values; the array added to the heap 
maps all indices to the undefined value. 

Suppose the instruction is MKINTARRAYEC. e" adds a new node to the heap such 
that an element within the bounds of the array points at an empty EC-queue. Anu 
select operation which tries to access an element outside the bounds of the array 
would produce an undefined value. In LI, the function is defined such that the 
indices within the specified bounds map to empty EC-queues and indices outside 
the bounds are mapped to undefined values. 

Therefore, given the <P//#7 = H f we get <P / /#' /+1 ) = H. + v 

Hence, given <p(S".) = S. and S\ is not the final state, <p(S" /+1 ) = S. + 1 for the 
mkintarray and mkintarrayec instructions. 

7. apply instruction 
A new function activation is added to Act \ +1 as a result of the execution of e. The 
first three instructions of the nre activation receive the closure, argument list and 
return link, respectively. Corresponding action occurs in LI. .'. under the given 
preconditions. <p A J Ac f j+ x ) = Act j+V 

e is deleted from EIS" . and instructions which received the closure, argument list 
or return link, if they become enabled, arc added to the set of enabled instructions 
to yield EIS' . , . LI acts in tha same manner to yield EIS ,. 

Therefore given that (p /7s (/:7.S" ; .) = /:7.S, we get <p fJS (EIS i+i ) = EIS j+l , 
provided that S '. is not a final state. 

The heap is unaffected, so that IT = hF . , and H. - H. ,. Since we have 



f if "V ~ H r il is t, ' iviall > truc lhat ( P// //, , + 1) = w ,+ r 
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.'. under the given preconditions, (p(S'. + 1 ) = S j+y 

The cases for tailapply and stream-tailapply are similar and are left as an 
exercise. 

8. RETURN instruction 

A glance at the transition rules for the return instruction in LI and L2 tells us 
that there is no difference between them, except that the instructions which 
become enabled in L2 are tagged executable. The heap is unaffected. Thus we 
can conclude that <pCS", +1 ) = S p given that qKS'p = S. and that 5". is not a final 
state. 

9. release instruction 

The execution of e' deletes the activation of e' from Act', to produce Act'. ,. 
Similarly, the activation of e disappers from Act. to produce Act. ,. Since <p(S"J 
= S p we conclude that <P Act (Act' i+ x ) = Act. + r ' 

EIS' j+l = EIST. - {e'} and EIS /+l = EIS j - {e}. Therefore, under the stated 
preconditions, ( P EIj ^EIS' j+1 ) = EIS. ,. 

The assertions of the validity of the mapping for the heap needs some comments. 
The transition rule for this instruction is identical in both machines. In LI, all 
nodes in the heap H. which were reachable only through instructions in the 
activation to which release belongs become unreachable. 

The base language ensures that a release instruction is enabled only after all the 
instructions which have pointers to nodes corresponding to structures - arrays, 
records, etc. on the heap have been executed. This is done by arranging the data 
flow graph for a function such that the RELEASE instruction is the last instruction to 
become enabled. This ensures that when release is enabled, the instructions 
which received structure operands have already executed; if the structures were 
pointed at only by the instructions, then their refent field must be 1 in ff. and 
would become zero after the execution of e and would be deleted from the heap. 
Therefore, the mapping qp^. still holds. 

Thus we conclude that if S . is not a final state and <p(5" ) = S. then after RELEASE 
executes. w(S* . .) = S ,. 

Wc demonstrated that the <p indeed provides the desired mapping. Similar reasoning may 
be used to show that the mapping p is preserved by instruction execution. The map p(S) is a 
member of an equivalence class under the similar relation. This is an artifact due to the 
different chunks which may be used to represent the same data structure, and hence, the 
heap. 

Thirdly, wc prove that <p and p satisfy the third condition for equivalence. Clearly, if S is 
linal then <p(.S'.) is final both will have EIS. = A7.S" = {}. Similarly, if .S". is final then 
p(.S" ) is final. 
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Finally, let S n and S'^ be the final states of machines LI and L2, respectively. By the 
previous two cinditions, <p(S~ n ) = S n and p(S n ) = 5' , by a judicious choice of chunks. 

We proved that at every step during the execution of program P the set of values 
represented on the heap were the same. Therefore, ResultValue u (S) - 
ResultValue^STJ.l 

We now argue informally that even if the Fetch function is not omniscient, that is, it does not 
mark as accessible all the chunks required during the execution of the instruction, the result 
produced by the computation is the same as would be if it were omniscient. Recall that if a chunk 
which is required to be accessed during the execution of an instruction is marked inaccessible, the 
instruction is made dormant and no change is made to the Act, H and C components of the machine. 
The state of the machine is changed only by the fact that the status of the instruction changes in the EIS 
component of the state. Some other instruction may be selected for execution; eventually when the 
chunk becomes accessible the instruction becomes executable. The order of execution of 
instructions is thus different. Let the sequence of states during the computation of program P on L2 (in 
which the instructions may become dormant) be S" Q S , V ..S" . The map tp gives us a corresponding 
sequence of states in LI. Since this is a non-deterministic state transition system, it can be shown that 
the result of this computation is the same as for the original sequence on LI, and so the result is the 
same. 



4.2 Discussion 

It was shown that L2 satisfies the specifications of Vim by proving that LI and L2 are equivalent 
This technique of taking a component of the Vim system (in this case, it is the structure memory) and 
designing an implementation which is formally proved to satisfy the specifications given by LI can be 
extended to design the entire machine. At each step of the implementation, the resulting formal model 
must be proven to satisfy the specifications of LI. This methodology of designing by successive 
refinement with formal proofs of equivalence between the original model and its refinement will be 
very useful in the design of more complex implementations of Vim, such as in a computer system with 
multiple processing elements. 
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Chapter Five 
A Base Language for Vim 



I shall now present a base language for Vim; I shall do this by describing the base language graph 
corresponding to the VimVal language constructs. These graphs are characterised by a property called 
safety. A graph is safe if every instruction (in the graph) which receives a structure operand becomes 
enabled before the activation, of which the instruction is a part, is removed from the set of activations 
by the release instruction. The firing of the instruction would cause the reference counts of the the 
operand structures to be appropriately decremented. The discussion in chapter 4 described why the two 
machines are equivalent for this base language. In terms of pragmatics, the use of safe graphs would 
ensure that the chunks which contain garbage values are reclaimed in the actual implementation of Vim. 
The base language described is not the only possible one; the intent of this chapter is to give the reader 
a flavor of how one might go about designing the language. No formal proof will be given to 
demonstrate that the graphs are indeed safe and that a compiler using the base language as its target 
language will always generate safe graphs; the interested reader may convince himself of the safety of 
programs written in this base language by examining each graph and the operational semantics of each 
of its instructions. 

5.1 The Let expression 

The let construct permits local bindings to be expressed and is of the form : 







let x x = 
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The base language graph for the above let expression is shown in figure 19. 
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Figure 18: Translation of a let expression 



5.2 Conditional Expression 

The conditional expression in VimVal is of the form : 

if /then g(x v x 2 xj 

else h(x v x 2 , ..., xj 

where g and h are data flow graphs and /denotes a graph that computes a boolean result In some 

graphs, the values of all the operands of an instruction are known at the time of compilation. It is 

necessary to send a signal to such instructions to enable them. If there is such an instruction in either of 

graphs g and h and the instruction is not in the graph of a let or tagcase expression inside g or /z, then 

the switch-signal instruction is used; it is omitted otherwise. Each branch of the if expression must 

produce the same number of signals; this is accomplished by feeding all the signals in an arm into a 

signal instruction which generates one signal. If neither of the arms produces signals, then the parts of 

the graph that deal with them maybe omitted. If the RHLEASL instruction is triggered by the signal 

produced by the if expression, and/ g and h arc all safe graphs, then it is the case that the graph for the 

conditional expression is also safe. 
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Figure 19: Translation of a conditional expression 



5.3 The Tagcase Expression 

Let T be a oneof with tags /,, /,, 

tagcase T 

tag t l \E [ (u v u 2 , ..., u a )\ 
tag/ 2 :/<: 2 (v r v 2 Vfr ): 



... / . The tagcase expression is 



endtag 



tag/ : /■; (z,,z, z ) 
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where the Fs are data flow graphs. The use of the switch-signal and signal instructions is governed 
by the same considerations as for the conditional expression. 




Figure 20: Translation of a lagcase expression 
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5.4 Function Application and Returns 

The syntax for function application in VimVal is : 

* x v x i X J 

where /is the name of a function. In most cases, the function application is performed by the apply 

operator. The arguments x 1 x n are collected into a single record all of whose elements are intially 

EC-elements. The code is shown in figure 22. The tailapply instruction is used in place of the apply 
whenever the compiler can recognize that a function application is tail- recursive. The instruction 
stream-tailapply is used only in the body of stream producers and will be discussed in the next 
section. 




Function 
template 
of / 



/ x, 



2 x. 



I I I I l~L 



RSET 



n x. 



RSET -i 



• • 



RSET -i 



Figure 21: Code for creating the argument record for function activation. 



The return instruction is used to dispatch the results computed by the function to the 
destinations listed in the return link, which is its first operand. The return-link was received by the 
template from the apply instruction. The results computed by the activation are packed into a record, 
tine fields of which are EC-elements. Values returned from a function arc similarly packed into a record. 
In most cases, one of the destinations for the signal produced by the return instruction is the release 
instruction for the activation. 
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return link 



Figure 22: Code for returning the result of an activation. 



5.5 Stream Producers and Consumers 

A stream is a sequence of values, all of the same type, that are passed in succession, one-at-a-time 
between functions. The operations on values of type stream of type Tare defined below where S and 5" 
are streams, and v is a value of type T. 

1. Q[7] : returns an empty stream (of elements of type T) which is the sequence of 
length zero. 

2. first(5) : The result is the value v which is the first element of the stream S. If S 
= Q (the empty stream), then the result is undef. 

3. rest(5) : The result is the stream left after removing the first clement of S. If 5 
= Q the result is undef. 

4. affix(v, S) : The result is the stream S' whose first element is v and whose 
remaining elements arc the stream S. 

5. cmpty(.V) : The result is true if .V = ^ false otherwise. 
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For a non-empty stream S, the following property is satisfied : 
S = affix(first(A'), rcst(S)) 

In Vim the storage representation for a stream is a chain of oneofs. Operations on streams are 
expressed in terms of operations on the components of the oneofs. The data structure for a stream 
whose elements are of type T is: 

stream[ 7] = oncoff emp/y: null; 

nonempty: recorders/: T; 

second: stream[71]] 

The following discussion describes the rules using which the compiler can translate the VimVal 
text into data flow graph. The translation rules specified are by no means complete; only the simpler 
cases are dealt with in this thesis and the more complex cases need further investigation. 

The expression Q for creating an empty stream is translated into an expression for creating a oneof 
with tag empty. 

make[emply: nil\ 

first(S) is tranlated into the following code: 

tagcase(S) 

tag empty: undef, 

tag nonempty: S.first 
cndtag 

rest(S) is tranlated into the following code: 

tagcase(.S) 

tag empty: undef; 

tag nonempty: S.rest 
endtag 

The code generated for the affix(v, 5) is shown below in figure 24. The instructions are so 
organized that the computation of the rest of the stream is suspended until some instruction demands it. 
When some computation attempts to perform the rest operation on the resulting stream, the suspension 
is replaced by a pointer to the next clement of the stream and a signal is sent to the instruction which 
initiates the computation of the next clement. 
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MKRECORDEC 
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RSET 



\ I i 



RSETSUSP 



Figure 23: The general form of the base language graph for the expression affix(v, S). /is the index of the instruction 
in the current template which starts the computation of the stream S. 



The translation for self-tail-recursive stream producers is quite interesting. I assume that the 
compiler can recognize stream producers which are self-tail-recursive. The use of tail recursion allows 
the activation template of the caller to be released before the computation of the callee is completed. 
This is a significant optimization since it results in a much lower amount of storage that is required for 
the computation. Mutually tail-recursive programs are translated naively, using simple APPLY and 
return instructions without taking advantage of the stream-tailapply instruction. 

Let /be a self-tail-recursive function that requires n arguments and produces a stream. Let the 

function be of the form : 

function J{x x x n ) returns stream[7]; 

body of function 
endfun; 

The compiler generates an auxiliary function f-aux from/ The code for the body of the function 
/ is generated using the rules specified above, except that every instance of affix(v, J{...)) is translated 
into the graph in figure 25. 

The VimVal text of f-aux is the same as that of the function/ The only difference is that each 
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closure for 
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argument 
record 



STREAMTAILAPPLY 



Figure 24: Translation of afTix(v,/...)) in the body of the function/ 



instance of affix(v, /...)) in/ is translated into the graph shown in figure 26. 

The correctness and generality of these translations are under current investigation and will be the 
subject of another treatise. 

5.6 Discussion 

We described a base language such that machines LI and L2 arc equivalent for all programs 
written in this language. Stated in another way. programs in this base language ensure that when a 
program halts, the only elements on the heap are those that represent the result value of the 
computation. Since the data structures are stored in chunks, this ensures that all chunks which were 
acquired during the computation and which arc not part of the result structure are reclaimed. 

'ITic base language uses early-completion elements for creating argument lists for function 
invocations and for creating records in which the result of a function invocation is returned. The use of 
early-completion elements in these records allows a function to be invoked even if all the arguments 
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Figure 25: A base language graph for the expression affix(v, /jr., x~ *J) in the body of / which is 

self-tail-recursive, is translated into the above graph in the body of faux. 



have not been evaluated. Similarly, early-completion queues in return records allows values to be 
returned to the caller even if the computation of all the values which are to be returned has not 
completed. The other use of the early-completion structures is in the construction of streams. 

A major use of the early-completion feature of the language is in the construction of arrays. 
Creation of arrays whose elements are then initialized by large computations can benefit from the use of 
EC-queues. Such techniques for increasing the amount of parallelism in programs are the subject of 
ongoing research. 
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Chapter Six 
Conclusion and Scope for Further Work 



The objective of the thesis was to develop a storage management strategy for Vim. An abstract 
architecture for Vim was informally discussed and some of the distinctive features of Vim explained in 
an informal manner. This was followed by a formal model LI of the abstract architecture. The thesis 
then went on to refine the model LI to include hierarchical storage consisting of main memory and disk. 
Chunks, which are the unit of storage allocation and reclamation of storage and the unit of data transfer 
between main store and disk, were used as the constituent of a new data structure called a ViM-tree. 
Vim -trees are used to represent structure values (arrays, records and oneofs). An automatic storage 
reclamation strategy was developed using reference counting. Particular attention was paid to ensure 
that the machine L2 exhibited desirable behaviour in the presence of EC-queues and suspensions. 

A concurrent objective of the thesis was to demonstrate the usefulness of the methodology of 
computer design by successive refinement. We started with an abstract machine and developed a 
formal specification for it. The machine model was then refined to include a storage model. In order to 
show that the refined model L2 (with hierarchical memory, paging, dormant instructions and tree 
structures for storing arrays, etc.) exhibited the same behaviour as LI for programs written in the base 
language discussed in the thesis, we proceeded to prove the equivalence of the two machines. A 
modification of the McGowan mapping was used to accomplish this. 

L2 represents a machine which is closer to an envisioned implementation. L2 may now be refined 
so that EC-queues, Function templates and activation templates would also be represented as data 
structures. This new model, say L3, may then be proved to be equivalent to 1.2. and hence to LI, using 
the kind of technique described in this thesis. Such successive refinement would finally yield a machine 
model which can be directly implemented to construct a real machine. 
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Future Research 

There are a number of topics which are natural extensions of the ideas and issues addressed in this 
thesis. 

1. An implementation of Vim : The abstract architecture may be successively 
refined to produce a model which reflects the characteristics of the physical 
elements of a machine - disk interaction, paging algorithms, process priorities, 
non-terminating computations, faults and exception handling, etc. Each model 
must be shown to be equivalent to the preceding model, and thus the final 
implementation would satisfy the specifications of LI and the two would be 
computationally equivalent. It is a matter of conjecture as to how far this process 
of refinement can be performed before the designer is overwhelmed by the 
details of the machine formalism. 

2. Storage Management and Guardians : Guardians are a special construct 
proposed in VimVal [13] which allows the programmer to express indeterminacy 
in computations. They are similar to the manager construct in Id [3] and allow 
the programmer to write programs for, say, data base transactions. It remains to 
be investigated how the incorporation of guardians in the abstract model would 
affect the reference counting scheme. 

3. Storage Management in Multiprocessors : It would be interesting to develop a 
model of Vim which has multiple processors and prove the equivalence of this 
model to LI for the base language in consideration in this thesis. The issues of 
storage allocation and reclamation and instruction scheduling can be formally 
addressed in this model. 

4. Extending the Rase Language : The base language presented in this thesis is 
being extended to express efficient computations on arrays. Judicious use of 
EC-queues should significantly increase the amount of concurrency in the 
program. This increase in parallelism can be exploited to overlap disk activities 
in a single processor implementation of Vim, or by multiple processors. VimVal 
constructs which corespond to these new base language constructs must be 
developed; preliminary research shows that naive extensions of VimVal 
introduces in the type system of VimVal. 
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